Miika Nissi

Highly Accessible Modus Themes for Neovim

Thu, 02 Nov 2023 01:13:34 -0400

Highly accessible themes for Neovim, conforming with the highest standard for color contrast between background and foreground values (WCAG AAA). This is a Neovim port of the original Modus Themes built for GNU Emacs.

Overview

The Modus Themes are designed for accessible readability. They conform with the highest standard for color contrast between background and foreground values. For small sized text, this corresponds to the WCAG AAA standard, which specifies a minimum contrast ratio of at least 7:1, while large sized and bold text have a contrast ratio of at least 4.5:1. Incidental text that is part of an inactive user interface component, or that are for pure decoration, have no contrast requirement.

This is a Neovim port of the original Modus Themes for GNU Emacs, and follows the design philosophy. It is not intended to be an exact 1:1 correspondence with GNU Emacs, but rather follows the spirit of the design and ensures conformity to the WCAG AAA guidelines.

This project is hosted on GitHub. Any issues and contributions should be directed there.

Features

Highly accessible — prioritizes color contrast and contains tinted, deuteranopia, and tritanopia theme variants
Extensive TreeSitter syntax highlighting and LSP integration
Supports most popular Neovim plugins
Switch between light (modus_operandi) and dark (modus_vivendi) mode automatically based on the background value set with vim.o.background
Provides extras to use Modus Themes with numerous other applications

Requirements

Neovim >= 0.8.0

Installation

Install the theme with your preferred package manager.

lazy.nvim

{ "miikanissi/modus-themes.nvim", priority = 1000 }

packer.nvim

use({ "miikanissi/modus-themes.nvim" })

vim-plug

Plug 'miikanissi/modus-themes.nvim'

Usage

Lua

vim.cmd([[colorscheme modus]]) -- modus_operandi, modus_vivendi

Vim Script

colorscheme modus " modus_operandi, modus_vivendi

Configuration

Ensure the configuration is set BEFORE loading the color scheme with colorscheme modus.

By default, the theme will choose between light (modus_operandi) and dark (modus_vivendi) based on the background value set with vim.o.background.

If using the default options, there is no need to explicitly call setup.

-- Default options
require("modus-themes").setup({
	-- Theme comes in two styles `modus_operandi` and `modus_vivendi`
	-- `auto` will automatically set style based on background set with vim.o.background
	style = "auto",
	variant = "default", -- Theme comes in four variants `default`, `tinted`, `deuteranopia`, and `tritanopia`
	transparent = false, -- Transparent background (as supported by the terminal)
	dim_inactive = false, -- "non-current" windows are dimmed
	hide_inactive_statusline = false, -- Hide statuslines on inactive windows. Works with the standard **StatusLine**, **LuaLine** and **mini.statusline**
	styles = {
		-- Style to be applied to different syntax groups
		-- Value is any valid attr-list value for `:help nvim_set_hl`
		comments = { italic = true },
		keywords = { italic = true },
		functions = {},
		variables = {},
	},

	--- You can override specific color groups to use other groups or a hex color
	--- Function will be called with a ColorScheme table
	--- Refer to `extras/lua/modus_operandi.lua` or `extras/lua/modus_vivendi.lua` for the ColorScheme table
	---@param colors ColorScheme
	on_colors = function(colors) end,

	--- You can override specific highlights to use other groups or a hex color
	--- Function will be called with a Highlights and ColorScheme table
	--- Refer to `extras/lua/modus_operandi.lua` or `extras/lua/modus_vivendi.lua` for the Highlights and ColorScheme table
	---@param highlights Highlights
	---@param colors ColorScheme
	on_highlights = function(highlights, colors) end,
})

Example Settings with Color and Highlight Overrides

require("modus-themes").setup({
	style = "modus_operandi", -- Always use modus_operandi regardless of `vim.o.background`
	variant = "deuteranopia", -- Use deuteranopia variant
	styles = {
		functions = { italic = true }, -- Enable italics for functions
	},

	on_colors = function(colors)
		colors.error = colors.red_faint -- Change error color to the "faint" variant
	end,
	on_highlights = function(highlight, color)
		highlight.Boolean = { fg = color.green } -- Change Boolean highlight to use the green color
	end,
})

Extras

Aerc (aerc)
Alacritty (alacritty)
Bat (bat)
Delta (delta)
Dunst (dunst)
Fish (fish)
Foot (foot)
GitUI (gitui)
iTerm (iterm)
Kitty (kitty)
Lua Table for testing and reference (lua)
Oomox/Themix (oomox)
PrismJS (prismjs)
qt5ct (qt5ct)
Terminator (terminator)
Tilix (tilix)
Tmux (tmux)
WezTerm (wezterm)
Windows Terminal (windows_terminal)
Xfce Terminal (xfceterm)
Xresources (xresources)
Yazi (yazi)
Zathura (zathura)
Zellij (zellij)

Contributing

Contributions are welcome. Feel free to create a pull request on GitHub to add support for any missing plugins, or report an issue.

Please ensure the WCAG AAA contrast requirements are met. You can use this contrast checker for reference.

Extras are generated using a template system.

How to create a new extra template:

Create a file such as lua/modus-themes/extras/extra-app.lua.
Add the name and output file extension to the extras table in lua/modus-themes/extras/init.lua.
Run the following command to generate new extras from the Modus Themes plugin directory:
```
./scripts/extras.sh
```
Ensure the newly created themes in the extras/ directory are correct. Please DO NOT commit them, as they are already automatically built by the CI.

Acknowledgements

Modus Themes: Original Modus Themes for GNU Emacs
Tokyo Night: Neovim theme used for inspiration and as a base project template

Setting up a Local Odoo 16 Development Server With Docker

Sat, 15 Jul 2023 23:48:21 -0400

Odoo is a framework and a suite of open source business applications including CRM, e-commerce, accounting, manufacturing, warehouse, and inventory management to name a few. It is fully customizable to every business need because its extensible architecture allows developers to modify existing applications and create new applications. I have ample experience solving business needs from small clients to larger enterprises using the Odoo framework. In this guide, I will share my personal development environment and help you create your own local development server for Odoo 16 utilizing Docker.

Installing Docker

To begin, we must first have Docker Engine and Docker Compose installed on our system. The installation will vary depending on what platform you’re on and detailed instructions for your platform can be found from the official Docker documentation. Here, I will share the installation process for Debian 11 and 12 or Ubuntu 20.04, 22.04, 22.10, and 23.04:

Uninstall Old Docker Versions

To make sure your system has no conflicting versions installed, it is a good idea to first run this command to uninstall them:

for pkg in docker.io docker-doc docker-compose podman-docker containerd runc; do sudo apt-get remove $pkg; done

Set Up Docker Repository

In order to get the latest Docker packages, we are using the official Docker repository.

Let’s first update the apt package index and install the prerequisite packages:

sudo apt-get update
sudo apt-get install ca-certificates curl gnupg

Next, we add the official Docker GPG key to ensure authenticity and security of our Docker packages:

Debian 11 and 12

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Ubuntu 20.04, 22.04, 22.10, and 23.04

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Install Docker Engine and Docker Compose

Now that the repository is all set up. We just need to update our package index and install the necessary Docker packages:

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Creating Odoo Configuration and Directory Structure

Now that we have Docker installed, we can start setting up our Odoo configuration. You are free to choose whatever directory works for you, but for the purpose of this tutorial, we will be placing our Odoo 16 files in /opt/odoo/16/ directory.

First, let’s create the directory and navigate inside of it:

mkdir -p /opt/odoo/16
cd /opt/odoo/16

Next, create another directory here that will house all the configuration files:

mkdir -p /opt/odoo/16/conf

Creating a Dockerfile

In the conf directory, we will create a Dockerfile which will contain instructions for Docker to build an image. A Docker image is essentially a template containing instructions for Docker to build a container out of.

nano /opt/odoo/16/conf/Dockerfile

In this file, you can install any additional external dependencies required by your custom Odoo modules. The following is a great basic template to use for your first Dockerfile:

FROM odoo:16
user root
RUN apt-get -y update && apt-get install -y git && apt-get install -y xmlsec1
RUN pip3 install --upgrade --no-cache-dir pip
RUN pip3 install --no-cache-dir astor
RUN pip3 install --no-cache-dir cachetools
RUN pip3 install --no-cache-dir openupgradelib
RUN pip3 install --no-cache-dir wheel
# Password security
RUN pip3 install --no-cache-dir zxcvbn

Here you can see the first line of this Dockerfile actually pulls the official Odoo 16 Docker image, which we are using to build a custom image on top of.

Setting up Odoo configuration

Next we will be creating a new directory inside the /opt/odoo/16/conf/ directory. The new directory will be the name of your Odoo development database. This will make sense when we have multiple Odoo instances running on our computers for different databases.

mkdir -p /opt/odoo/16/conf/odoo1

Here, we will first add our Odoo configuration file to a config directory. To learn more about Odoo configuration files, you may read the official Odoo documentation.

mkdir -p /opt/odoo/16/conf/odoo1/config/
nano /opt/odoo/16/conf/odoo1/config/odoo.conf

Here is a simple example of an Odoo configuration file you can use:

[options]

# ADMIN PASSWORD
admin_passwd = SecretPassword123

# DATABASE
db_host = db
db_port = 5432
db_user = odoo
db_name = False
db_password = SecretDBPassword123
db_maxconn = 50
list_db = True

# PROXY
proxy_mode = False

# LOGGING
logfile =
logrotate = False
syslog = False
log_handler = :INFO
log_level = debug

# MISC:
without_demo = all

workers = 4
limit_memory_hard = 3360319078
limit_memory_soft = 2688255262
limit_request = 8192
limit_time_cpu = 300
limit_time_real = 600
max_cron_threads = 2
server_wide_modules = base,web
gevent_port = 8072
http_port = 8069

# DIRECTORIES
data_dir = /var/lib/odoo/
addons_path = /usr/lib/python3/dist-packages/odoo/addons,/opt/odoo/16/addons/

In the configuration file, the setting you might change is the addons_path option. The addons path is a comma separated list of directory paths which contain Odoo modules. In this basic example we are only using two directory paths - base Odoo addons path and the root directory of opt/odoo/16/addons (which we will get back to later in this guide).

Docker Compose Configuration

Now that we have created our Dockerfile with instructions for building a Docker image containing all of our system tools and packages, and we have a simple Odoo configuration file set up, we can move on to creating a Docker compose file which will take the Docker image and build a container where our Odoo instance will be running on.

nano /opt/odoo/16/conf/odoo1/docker-compose.yml

The following is an example of a basic docker compose file you may use to get started. I won’t be going on in depth what all the different options mean. But the most important parts to take note of are as follows:

Container name: This will be the name of the container to help you identify what the purpose of the container is. Here we are using the name of our Odoo database, odoo1 as the identifier.
Ports: This option defines what local system ports will be used to access certain ports on the container. Odoo runs on the port 8069 by default, so we will be using that. If you have multiple Odoo containers running on your system, you need to assign different ports for each container so that they won’t overlap. For example, you could set up your local port 8079 to connect to the container’s port 8069 by typing “8079:8069” instead.
Volumes: Volumes will map certain directories from your system to be accessible in the container. This is necessary so that the container can find your Odoo addons and configuration files. We are also mapping the file store and database of the container to a named volume so that the data will be persistent even if the container is taken down.

version: "3.1"
services:
  web:
    image: custom-odoo:16.0
    container_name: odoo1
    depends_on:
      - db
    restart: always
    ports:
      - "8069:8069"
      - "8072:8072"
    volumes:
      - odoo1-web-data:/var/lib/odoo
      - ./config:/etc/odoo
      - /opt/odoo/16/addons:/opt/odoo/16/addons
      - /var/log/odoo:/var/log/odoo
    environment:
      - PASSWORD = SecretDBPassword123
  db:
    image: postgres:13
    container_name: odoo1_postgres
    environment:
      - POSTGRES_DB=postgres
      - POSTGRES_PASSWORD=SecretPassword123
      - POSTGRES_USER=odoo
      - PGDATA=/var/lib/postgresql/data/pgdata
    volumes:
      - odoo1-db-data:/var/lib/postgresql/data/pgdata
volumes:
  odoo1-web-data:
  odoo1-db-data:

Custom Odoo Modules Directory

Lastly, the guide would not be complete without creating a location for your custom Odoo modules that you’re trying to develop. For simplicity, we will just create a single directory which will contain all of your custom Odoo modules.

mkdir -p /opt/odoo/16/addons/

You may now add any of your custom modules in this directory. Once we boot up our Odoo container, they will be available to you inside the Odoo applications list.

Recap of the configuration

To recap, we created a Dockerfile which has instructions for building the Docker image for Odoo. Then we set up our Odoo configuration for a database called odoo1. We also created a Docker Compose file which will build the Odoo container. Lastly, we created a directory to house all of your custom Odoo modules.

If you have followed the guide correctly, you should have a directory tree that looks as follows:

/opt/odoo
└── 16
    ├── addons
    └── conf
        ├── Dockerfile
        └── odoo1
            ├── config
            │   └── odoo.conf
            └── docker-compose.yml

Running the Configuration

We are all done with the configuration. Now we just need to create the Docker image and then run our first Odoo container.

Building the Docker Image for Odoo

After running this command, we would only need to run it again in order to build a new image in case there is an upstream Odoo update or if we modify our Dockerfile with additional instructions.

cd /opt/odoo/16/conf/
sudo docker build -t custom-odoo:16.0 .

Creating the Docker container for an Odoo instance

The following command will create a new Odoo container from our Docker compose file if it doesn’t yet exist. The same command will also be used whenever we reboot our local Odoo server.

sudo docker compose -f /opt/odoo/16/conf/odoo1/docker-compose.yml up -d --force-recreate

If you followed the guide closely, you should now be able to navigate to http://localhost:8069 to log in to your Odoo database. The credentials will be admin as the username and the password will be the password defined in the odoo.conf file - in our case SecretPassword123.

To view Odoo logs from the container we can run this command:

sudo docker logs -f --tail=500 odoo1

Bonus Tips

Due to the way we have set up our directory structure, we can now easily duplicate this setup for any other Odoo version or have multiple Odoo instances running on our machine.

To set up an Odoo instance for another Odoo version, all you have to do is copy the entire /opt/odoo/16/ directory into /opt/odoo/<version_number> and then go through the files and change each instance of 16 into the version number you want to use.

In the same vein, to create an additional Odoo instance you just copy the /opt/odoo/16/conf/odoo1/ directory into /opt/odoo/16/conf/<database_name> and change the instances of odoo1 with your new database name.

For both of these, you need to also change the default ports in the docker-compose.yml file to avoid overlap. See the earlier mention of the ports above.

Conclusion

Hopefully this guide has helped you create a local Odoo development server or given you an overview of running Odoo in a Docker container. Feel free to reach out to me via email at miika@miikanissi.com for any comments, feedback, or assistance.

Grammar and Spell Checker in Neovim with LTeX Language Server

Sat, 11 Feb 2023 15:34:16 -0500

LTeX Language Server is an LSP for LanguageTool that can be embedded into Nvim LSP protocol to provide real time grammar and spell checking for most commonly used text formats such as Markdown, LaTeX, and reStructuredText. In this guide, I will show how to add LTeX Language Server to an existing LSP setup with nvim-lspconfig and Mason, and how to add a custom dictionary for words that are not recognized by the LanguageTool proofreading service.

Custom Dictionary Using Built-in Vim Spell Checker

Vim and Neovim come with a built-in spell checker tool spell that can generate a spell file, which we can use to give LTeX Language Server an additional dictionary.

First, we define the spell file location as follows:

vim.opt.spellfile = vim.fn.stdpath("config") .. "/spell/en.utf-8.add"

This will tell Neovim the location of the spell file dictionary at ~/.config/nvim/spell/en.utf-8.add. We need to make sure this file exists in our system. We can create it by doing the following:

mkdir -p ~/.config/nvim/spell
touch ~/.config/nvim/spell/en.utf-8.add

To add words to this dictionary in Neovim you can add the word under the cursor by typing zg.

Adding the Custom Dictionary to LTeX Language Server

Next, we create a Lua function that loops all the words in the spell file and creates a table of words from it.

local words = {}
for word in io.open(vim.fn.stdpath("config") .. "/spell/en.utf-8.add", "r"):lines() do
	table.insert(words, word)
end

Finally, in order to have LTeX Language Server use this words table as an additional dictionary we configure the following in the LTeX Language Server settings. This assumes you already have LTeX Language Server installed and configured in Neovim:

--
-- ...
--
settings = {
    ltex = {
        dictionary = {
            ["en-US"] = words,
        },
    },
},
--
-- ...
--

Conclusion

It is very straightforward to add a custom dictionary to LTeX Language Server in Neovim. This guide did not cover all the initial setup for getting an LSP up and running in Neovim, but if you need a reference for that you can check my Neovim configuration on GitHub. You can also reach out to me via email at miika@miikanissi.com.

Understanding the Unix Philosophy

Sat, 22 Oct 2022 00:19:51 -0400

The Unix philosophy originated in the early days of Unix as a set of rules and approaches to designing a simple yet capable operating system. The point of the philosophy has evolved over the years and has often been misunderstood to simply mean writing small programs or dividing a program into small modules/functions. In this post, I will try to explain what Unix philosophy is and present practical reasons to follow it.

“This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.” - Doug McIlroy

The above is a summarized version of the Unix philosophy by Doug McIlroy, the inventor of Unix pipes and one of the founders of the Unix tradition.

Write Programs That Do One Thing and Do It Well

Perhaps the most widely understood part of the Unix philosophy is writing small programs that each do one thing. The purpose of this is to avoid large monolithic structures which will eventually become hard to maintain as they grow larger and software requirements change. By creating programs that do one thing makes it easier in the future to change parts of them or replace a program with a different one as requirements change.

This is usually where most people’s understanding of Unix philosophy stops and they end up missing the rest of the picture, which is just as important.

Write Programs to Work Together

Now that we have these small programs each doing a single task we need to be able to connect them to each other in order to solve real life applications. This is where Unix pipes come into play. Unix pipes are a simple communication method between programs that allows them to receive a text input from one program and output a new text output, which can then be used by something else. In a way, each program acts as a filter — They take an input, modify it, and then outputs the result.

Unix pipes are not the only way for programs to communicate with each other, but the important part is the principle of connecting programs with a simple interface and thus making each program interchangeable.

Notice how in the original definition the output of a program should be a text stream — not JSON, or XML, or any other structured data format. By using a universal text interface, each program does not need their own parser to parse different data inputs. Personally, I have nothing against these structured data formats, but this is something to consider when creating a new program. Does it need a complicated data format, or could it simply output text streams?

Unix Philosophy in Practice

The following is a trivial example showcasing the Unix philosophy in Bash using Unix pipes:

curl -s https://en.wikipedia.org/wiki/Unix_philosophy | \
grep "This is the Unix philosophy:" | \
sed -e 's/<[^>]*>//g' | \
sed 's/$/ - Doug McIlroy/' | \
cowsay -f tux

Which results in the following output:

 ________________________________________
/ This is the Unix philosophy: Write     \
| programs that do one thing and do it   |
| well. Write programs to work together. |
| Write programs to handle text streams, |
| because that is a universal interface. |
\ - Doug McIlroy                         /
 ----------------------------------------
   \
    \
        .--.
       |o_o |
       |:_/ |
      //   \ \
     (|     | )
    /'\_   _/`\
    \___)=(___/

Here we are combining four different programs in order to complete a trivial task in a way that the creators of these programs might have never imagined they were going to be used for.

First, we use the curl program to transfer the desired HTML page from Wikipedia. Next, we use the grep program on the output to get the line containing “This is the Unix philosophy:”. Then in order to clean the HTML tags, we use the sed program to parse and remove the tags. We then use sed again to append an extra bit of text at the end of the output. Finally, we use a cool program called cowsay to create an ASCII art speech bubble of the sentence.

The point I would like to highlight with this example is how we were able to complete a specialized task without having to create a new specific program to do so. We got text from a web page, parsed it and then transformed it into ASCII art by utilizing programs which each do one simple task — and it took just a few lines of Bash script to achieve.

Conclusion

To conclude, Unix philosophy is about writing lots of programs that do one thing well and having those programs connect with a simple text based communication via inputs and outputs. Although it can be applied to these, Unix philosophy is not about microservices, APIs, object-oriented programming, or any other modern buzzword.

If you have any thoughts on Unix philosophy you’d like to contribute, email me at miika@miikanissi.com.

Deploying Django Web Application in Docker With PostgreSQL, NGINX, and Gunicorn

Sun, 16 Oct 2022 14:19:10 -0400

I recently created a clean art portfolio website for my wife at christinanissi.com and I wanted to deploy it in Docker. As I was looking for the best solution for my needs, I stumbled upon many guides that ran the Django web application inside a Docker container behind an NGINX reverse proxy which also ran in a container. However, this solution has many downsides, which you can read more about from this article.

In this post I will show my solution which runs NGINX on the host server while the actual Django web application is running inside a container on a Gunicorn WSGI server. I’m also using poetry to manage my python requirements, but you can use the traditional approach of requirements.txt file (or manually manage python packages in the Dockerfile).

Dockerfile and Docker Compose to Run Gunicorn WSGI Server and PostgreSQL

To start off, I have created a Dockerfile which builds a Docker Image suitable for the container based on Alpine Linux.

# Pull python image
FROM python:3.10-alpine

# Set work directory
WORKDIR /usr/src/app

# Set python env variables
ENV PYTHONUNBUFFERED 1
ENV PYTHONDONTWRITEBYTECODE 1

# Install pip package dependencies
RUN apk update \
    && apk add postgresql-dev gcc python3-dev musl-dev g++

# Install dependencies with poetry
RUN pip install -U --pre pip poetry
ADD poetry.lock .
ADD pyproject.toml .
RUN poetry config virtualenvs.create false
RUN poetry install --no-interaction --no-root

# Copy and set entrypoint as executable
COPY ./entrypoint.prod.sh .
RUN sed -i 's/\r$//g' /usr/src/app/entrypoint.prod.sh
RUN chmod +x /usr/src/app/entrypoint.prod.sh

# Copy project
COPY . .

# Run entrypoint
ENTRYPOINT ["/usr/src/app/entrypoint.prod.sh"]

To summarize the Dockerfile, I first begin by using the official Alpine Linux Python image as a base. I then install some additional packages which are required to build Werkzeug Python package, among other things. Next, I use poetry to install the Python dependencies. Lastly, I copy the project files inside the image, set the entry point script as executable and define the image entry point as that script. The entry point script in my case just checks if PostgreSQL is running and when it is, it begins executing the command defined in the docker compose file:

#!/bin/sh

if [ "$DATABASE" = "postgres" ]
then
    echo "Waiting for postgres..."

    while ! nc -z $DB_HOST $DB_PORT; do
      sleep 0.1
    done

    echo "PostgreSQL started"
fi

exec "$@"

As I mentioned earlier, I am running the Django web application with a Gunicorn WSGI server. This is done by using the following Docker Compose file. I am also running my PostgreSQL database inside a container with the default Alpine Linux PostgreSQL image.

version: "3.9"

services:
  db:
    image: postgres:14-alpine
    volumes:
      - postgres_data:/var/lib/postgresql/data/
    env_file:
      - ./.env.prod.db
  web:
    build:
      context: ./src
      dockerfile: Dockerfile.prod
    command: gunicorn christinanissi.wsgi:application --bind 0.0.0.0:8000
    volumes:
      - .:/code:cached
      - ./src/staticfiles:/usr/src/app/staticfiles
      - ./src/mediafiles:/usr/src/app/mediafiles
    ports:
      - "8005:8000"
    env_file:
      - ./.env.prod
    depends_on:
      - db
volumes:
  postgres_data:

The important details here are to note that I am using bind mounts instead of named volumes. This is important as we need access to this data on the host server for our NGINX configuration. I am also opening the Gunicorn server to a local port 8005 on the host server, which is how we can access it from NGINX.

After building the image and running our containers, we can move on to the NGINX configuration.

NGINX Configuration as a Reverse Proxy on the Host Machine

Now we should have two containers running on our server — the PostgreSQL container and our web application container running a Gunicorn WSGI server which is open to a local port 8005. To set up the NGINX reverse proxy we need to listen to port 80 for HTTP traffic (HTTPS traffic comes from port 443 which I won’t go over in this guide). We define the server name and then to connect the traffic to our Gunicorn WSGI server we use NGINX proxy pass to direct the traffic to our local port 8005. We need to also make sure that the local WSGI server gets the correct headers from each request, so we also pass those.

In the last section, I mentioned how I mounted the static and media file directories as bind mounts. The reason for that is so we can access the files with NGINX on the host machine, since we don’t want to serve the static files with a WSGI server (that is bad practice and very slow compared to NGINX). To serve the static and media files with NGINX, we define the URL location such as /static/ and the path to the bind mount where these static files reside on the host server.

server {
    listen 80;
    listen [::]:80;

    server_name <host_name>;

    location / {
        proxy_pass http://localhost:8005;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_redirect off;
    }

    location /static/ {
        alias <path_to_project_dir>/src/staticfiles;
    }

    location /media/ {
        alias <path_to_project_dir>/src/mediafiles;
    }
}

Conclusion

By containerizing only the Django web application and PostgreSQL database while having NGINX running on the host machine we can make sure that our NGINX server is always running and we can also have multiple web applications or static websites running on the same server as they are not limited to a docker container.

To see the full configuration for this web application I used as an example in this guide, you can visit its git repository.

How to Setup Nvim LSP for Code Analysis, Autocompletion and Linting

Fri, 15 Jul 2022 17:50:01 -0400

Neovim or Nvim has come a long way to overtake vim with support of a multitude of new features natively out of the box. One of these features is the support for the Language Server Protocol (LSP), which means Nvim acts as a client to LSP servers. In order to take advantage of this feature, there are a couple of important plugins that do the heavy lifting of getting a working LSP server and client communication set up. In this post I will go over what you need to get started on how to set up Nvim LSP client for analyzing code, autocompletion and even automatic code linting and fixing.

Installing the Nvim Plugins With Packer

To get started, we first need to install the plugins. My preferred Nvim plugin manager is Packer, but this step can be done with any other plugin manager as well. Please note, I am configuring Nvim in an init.lua file. To learn more about how to configure Nvim in Lua you may refer to this helpful guide.

require('packer').startup(function(use)
    --
    -- ...
    --
	use({
		"neovim/nvim-lspconfig",
		requires = {
			-- Automatically install LSPs to stdpath for neovim
			"williamboman/mason.nvim",
			"williamboman/mason-lspconfig.nvim",
		},
	}) -- Collection of configurations for built-in LSP client
	use("jose-elias-alvarez/null-ls.nvim") -- Null ls is used for code formatting and pylint analysis
    use 'hrsh7th/nvim-cmp' -- Autocompletion plugin
    use 'hrsh7th/cmp-nvim-lsp' -- Autocompletion with LSPs
    --
    -- ...
    --
end)

After saving the init.lua we can run :PackerSync to install the declared packages.

Installing and configuring LSP Servers

In order to install and configure the LSP servers used by the Nvim LSP client, we use a helpful plugin called mason.nvim and mason-lspconfig.nvim. It is not necessary to use this plugin as each LSP server can be installed manually, but I like to use this plugin for convenience.

Below is a snippet of my setup for mason.nvim. For a full list of supported LSPs refer to this manual.

First, we define the common on_attach and capabilities functions for the LSPs. In the on_attach function we define the keymappings to interact with the LSP server. In capabilities function we hook the autocompletion plugin, so we get LSP completion suggestions.

local capabilities = vim.lsp.protocol.make_client_capabilities()
capabilities = require("cmp_nvim_lsp").default_capabilities(capabilities)

local on_attach = function(_, bufnr)
	local nmap = function(keys, func, desc)
		if desc then
			desc = "LSP: " .. desc
		end

		vim.keymap.set("n", keys, func, { buffer = bufnr, desc = desc })
	end

	-- Theme, colors and gui
	nmap("<leader>rn", vim.lsp.buf.rename, "[R]e[n]ame")
	nmap("<leader>ca", vim.lsp.buf.code_action, "[C]ode [A]ction")

	nmap("gd", vim.lsp.buf.definition, "[G]oto [D]efinition")
	nmap("gr", require("telescope.builtin").lsp_references, "[G]oto [R]eferences")
	nmap("gI", vim.lsp.buf.implementation, "[G]oto [I]mplementation")
	nmap("<leader>D", vim.lsp.buf.type_definition, "Type [D]efinition")
	nmap("<leader>ds", require("telescope.builtin").lsp_document_symbols, "[D]ocument [S]ymbols")
	nmap("<leader>ws", require("telescope.builtin").lsp_dynamic_workspace_symbols, "[W]orkspace [S]ymbols")

	-- See `:help K` for why this keymap
	nmap("K", vim.lsp.buf.hover, "Hover Documentation")
	nmap("<C-k>", vim.lsp.buf.signature_help, "Signature Documentation")

	-- Lesser used LSP functionality
	nmap("gD", vim.lsp.buf.declaration, "[G]oto [D]eclaration")
	nmap("<leader>wa", vim.lsp.buf.add_workspace_folder, "[W]orkspace [A]dd Folder")
	nmap("<leader>wr", vim.lsp.buf.remove_workspace_folder, "[W]orkspace [R]emove Folder")
	nmap("<leader>wl", function()
		print(vim.inspect(vim.lsp.buf.list_workspace_folders()))
	end, "[W]orkspace [L]ist Folders")

	-- Create a command `:Format` local to the LSP buffer
	vim.api.nvim_buf_create_user_command(bufnr, "Format", function(_)
		vim.lsp.buf.format()
	end, { desc = "Format current buffer with LSP" })
end

Next, we need to define the LSP servers we want to enable and pass any custom settings. Following is what servers I’m using. You can customize the list as you wish. For the full list of available LSP servers refer to this document.

local servers = {
	pyright = {},
	eslint = {
		codeAction = {
			disableRuleComment = {
				enable = true,
				location = "separateLine",
			},
			showDocumentation = {
				enable = true,
			},
		},
		codeActionOnSave = {
			enable = false,
			mode = "all",
		},
		format = false,
		nodePath = "",
		onIgnoredFiles = "off",
		packageManager = "npm",
		quiet = false,
		rulesCustomizations = {},
		run = "onType",
		useESLintClass = false,
		validate = "on",
		workingDirectory = {
			mode = "location",
		},
	},
	bashls = {},
	cssls = {},
	html = {},
	jsonls = {},
	lemminx = {},
	gopls = {},
	lua_ls = {
		Lua = {
			workspace = { checkThirdParty = false },
			telemetry = { enable = false },
			diagnostics = {
				globals = { "vim" },
			},
		},
	},
}

In this final part, we pass these functions and the list of servers to mason.nvim which handles the rest.

-- MASON.NVIM
require("mason").setup()

-- MASON-LSPCONFIG.NVIM
local mason_lspconfig = require("mason-lspconfig")
mason_lspconfig.setup({
	ensure_installed = vim.tbl_keys(servers),
})

mason_lspconfig.setup_handlers({
	function(server_name)
		require("lspconfig")[server_name].setup({
			capabilities = capabilities,
			on_attach = on_attach,
			settings = servers[server_name],
		})
	end,
})

Enable Autocompletion and Add Additional Keybindings

The following snippet adds custom keybindings for autocompletion:

-- nvim-cmp setup
local cmp = require 'cmp'
cmp.setup {
    snippet = {
        expand = function(args)
            luasnip.lsp_expand(args.body)
        end,
    },
    mapping = cmp.mapping.preset.insert({
        ['<C-d>'] = cmp.mapping.scroll_docs(-4),
        ['<C-f>'] = cmp.mapping.scroll_docs(4),
        ['<C-Space>'] = cmp.mapping.complete(),
        ['<CR>'] = cmp.mapping.confirm {
            behavior = cmp.ConfirmBehavior.Replace,
            select = true,
        },
        ['<Tab>'] = cmp.mapping(function(fallback)
            if cmp.visible() then
                cmp.select_next_item()
            elseif luasnip.expand_or_jumpable() then
                luasnip.expand_or_jump()
            else
                fallback()
            end
        end, { 'i', 's' }),
        ['<S-Tab>'] = cmp.mapping(function(fallback)
            if cmp.visible() then
                cmp.select_prev_item()
            elseif luasnip.jumpable(-1) then
                luasnip.jump(-1)
            else
                fallback()
            end
        end, { 'i', 's' }),
    }),
    sources = {
        { name = 'nvim_lsp' },
        { name = 'luasnip' },
    },
}

Automatic Code Linting and Fixing on Save Using Null-ls

So far, we have installed all the necessary plugins and enabled LSP servers with custom keybindings and autocompletion. Now we can use a plugin called null-ls to automatically use any available linters on a file to fix code formatting on file save. Refer to the available sources in the manual.

-- NULL-LS.NVIM
-- LSP formatting filter
local lsp_formatting = function(bufnr)
	vim.lsp.buf.format({
		filter = function(client)
			-- Ignore formatting from these LSPs
			local lsp_formatting_denylist = {
				eslint = true,
				lemminx = true,
				lua_ls = true,
			}
			if lsp_formatting_denylist[client.name] then
				return false
			end
			return true
		end,
		bufnr = bufnr,
	})
end

local augroup = vim.api.nvim_create_augroup("LspFormatting", {})
require("null-ls").setup({
	-- you can reuse a shared lspconfig on_attach callback here
	on_attach = function(client, bufnr)
		if client.supports_method("textDocument/formatting") then
			vim.api.nvim_clear_autocmds({ group = augroup, buffer = bufnr })
			vim.api.nvim_create_autocmd("BufWritePre", {
				group = augroup,
				buffer = bufnr,
				callback = function()
					lsp_formatting(bufnr)
				end,
			})
		end
	end,
	sources = {
		require("null-ls").builtins.formatting.prettier.with({
			extra_filetypes = { "xml" },
		}),
		require("null-ls").builtins.formatting.black,
		require("null-ls").builtins.formatting.djlint,
		require("null-ls").builtins.formatting.isort,
		require("null-ls").builtins.formatting.stylua,
		require("null-ls").builtins.diagnostics.djlint,
		require("null-ls").builtins.diagnostics.flake8,
		require("null-ls").builtins.diagnostics.pylint,
	},
})

Afterword

Setting up the Nvim LSP client to work with different LSP servers can seem a bit intimidating, as most things need to be configured manually. The benefit of this is that most everything on how the LSP client behaves can be customized, from keybindings to default behavior. There are plenty of other things that can be customized, but this basic setup should get you started on using the power of LSP servers in Nvim. If you need more assistance or have any ideas for improvement, feel free to email me at miika@miikanissi.com.

Laptop Dual Monitor Hot Plug Setup for BSPWM

Fri, 10 Jun 2022 20:35:10 -0400

There are many features people take for granted on a typical desktop environment such as Gnome or KDE. One of these features is the support for hot plugging an external monitor to a laptop while it’s running and having your desktop environment set everything up automatically. On a minimal window manager setup, features like these are typically missing, and you are required to configure everything manually. This post will go over my own monitor hot plugging setup and scripts for BSPWM. Every window manager is different, and this configuration might not work for i3 or dwm, but it might give an idea of things that need to be considered.

BSPWM Startup

The first thing to consider with an external monitor setup is what happens on startup. When you boot up your laptop with no external monitors connected, you should have everything on your laptop display. However, if you have an external monitor attached on boot up, you should allocate some workspaces and a status bar to both monitors.

Every time BSPWM loads up, it automatically runs its configuration file located in ~/.config/bspwm/bspwmrc. This configuration file is just a shell script, so you can run any command-line commands and tools directly inside the configuration file. In this file we can define the amount of workspaces to create depending on what monitors are connected.

In the following snippet of the configuration file, we first define the internal and external monitor connected to the laptop. You can get the monitor names by running xrandr -q while your external monitor is connected. After defining the monitors, we check to see if BSPWM is loading for the first time of the session. This is important because we don’t want to create additional workspaces every time BSPWM is reloaded. We can access this information by getting the first passed parameter with $1. This parameter tells us the amount of reloads in the session. If the number is 0 we know that we are loading BSPWM for the first time. Next, we use XRandR to query for the status of the external monitor. If it is connected, we assign half of the workspaces to it and the other half to the internal monitor. If the external monitor is not connected, we create all 10 workspaces on the internal monitor.

INTERNAL_MONITOR="eDP"
EXTERNAL_MONITOR="HDMI-A-0"
# on first load setup default workspaces
if [[ "$1" = 0 ]]; then
  if [[ $(xrandr -q | grep "${EXTERNAL_MONITOR} connected") ]]; then
    bspc monitor "$EXTERNAL_MONITOR" -d 1 2 3 4 5
    bspc monitor "$INTERNAL_MONITOR" -d 6 7 8 9 10
    bspc wm -O "$EXTERNAL_MONITOR" "$INTERNAL_MONITOR"
  else
    bspc monitor "$INTERNAL_MONITOR" -d 1 2 3 4 5 6 7 8 9 10
  fi
fi

External Monitor Is Connected During a Session

Next, we create a function where we write the logic which we want to happen when an external monitor is plugged in during the session. Here we simply want to move half of the workspaces to the newly connected monitor, and we also want to make sure that the external monitor becomes the new primary monitor.

monitor_add() {
  # Move first 5 desktops to external monitor
  for desktop in $(bspc query -D --names -m "$INTERNAL_MONITOR" | sed 5q); do
    bspc desktop "$desktop" --to-monitor "$EXTERNAL_MONITOR"
  done

  # Remove default desktop created by bspwm
  bspc desktop Desktop --remove

  # reorder monitors
  bspc wm -O "$EXTERNAL_MONITOR" "$INTERNAL_MONITOR"
}

External Monitor Is Removed

When the external monitor is removed, we essentially want the opposite to happen. We want to move all the workspaces (and the windows they contain) from our external monitor back to the internal monitor, which becomes the new primary monitor.

monitor_remove() {
  # Add default temp desktop because a minimum of one desktop is required per monitor
  bspc monitor "$EXTERNAL_MONITOR" -a Desktop

  # Move all desktops except the last default desktop to internal monitor
  for desktop in $(bspc query -D -m "$EXTERNAL_MONITOR");	do
    bspc desktop "$desktop" --to-monitor "$INTERNAL_MONITOR"
  done

  # delete default desktops
  bspc desktop Desktop --remove

  # reorder desktops
  bspc monitor "$INTERNAL_MONITOR" -o 1 2 3 4 5 6 7 8 9 10
}

Putting It All Together

Now that we have our functions declared, all that is missing is writing the logic to trigger them. This is done at the end of the configuration file. Here we once again use XRandR to check for the state of our external monitor. If it is connected we want to set up its resolution, position and to make it the primary monitor. After that, we check if the monitor already has half of the workspaces on it. If not, we know this monitor was recently connected, and we want to run our monitor_add function.

In the situation, we only have one monitor connected, and we check to see if it already has all the workspaces assigned to it. If that is not the case, we run the monitor_remove function. In this case, we also use XRandR to only set up the internal monitor.

if [[ $(xrandr -q | grep "${EXTERNAL_MONITOR} connected") ]]; then
  # set xrandr rules for docked setup
  xrandr --output "$INTERNAL_MONITOR" --mode 1920x1080 --pos 0x0 --rotate normal --output "$EXTERNAL_MONITOR" --primary --mode 1920x1080 --pos 1920x0 --rotate normal
  if [[ $(bspc query -D -m "${EXTERNAL_MONITOR}" | wc -l) -ne 5 ]]; then
    monitor_add
  fi
  bspc wm -O "$EXTERNAL_MONITOR" "$INTERNAL_MONITOR"
else
  # set xrandr rules for mobile setup
  xrandr --output "$INTERNAL_MONITOR" --primary --mode 1920x1080 --pos 0x0 --rotate normal --output "$EXTERNAL_MONITOR" --off
  if [[ $(bspc query -D -m "${INTERNAL_MONITOR}" | wc -l) -ne 10 ]]; then
    monitor_remove
  fi
fi

Automatically Detect a Screen Change

At this point our configuration is fully working and every time we reload BSPWM it checks for the state of the monitors and sets them up correctly. However, we have not made BSPWM make an automatic reload when a screen change occurs. In order to do this, we need to create a custom Udev rule. Udev monitors device events, and we can use it with a oneshot systemd service to reload BSPWM automatically when a monitor gets plugged in or out. I won’t be going into detail on how Udev rules work, but you can read more about them here.

In order to trigger a BSPWM reload from udev as a user process, we need to use a oneshot systemd service. Copy this to a file located at ~/.config/systemd/user/bspwm-reload.service:

[Unit]
Description=Reload BSPWM

[Service]
Type=oneshot
ExecStart=/bin/bash -c "bspc wm -r"
StandardOutput=journal

Next, we create the udev rule which triggers the systemd service process. In the following snippet, make sure to replace the m after /bin/su and /home/ as your own username. Save this snippet in a file called /etc/udev/rules.d/99-reload-monitor.rules.

ACTION=="change", SUBSYSTEM=="drm", RUN+="/bin/su m --command='systemctl --user start bspwm-reload.service'"

Bonus: Set a Wallpaper and Run Polybar

After a new monitor is added, it won’t have any wallpaper by default. This is why in the configuration file after we set up our monitors we want to use some program such as feh to add a wallpaper. This can be done with the following snippet:

feh --no-fehbg --bg-scale <path-to-wallpaper>

The simplest way of setting Polybar is to first make sure we kill all existing polybar processes, and then we relaunch it based on what monitors are connected. The following polybar command has the option --reload which will monitor any changes to polybar and automatically reload it when a configuration is changed.

# Kill and relaunch polybar
killall -q polybar
while pgrep -u $UID -x polybar > /dev/null; do sleep 2; done
if [[ $(xrandr -q | grep "${EXTERNAL_MONITOR} connected") ]]; then
  polybar --reload primary -c ~/.config/polybar/config.ini </dev/null >/var/tmp/polybar-primary.log 2>&1 200>&- &
  polybar --reload secondary -c ~/.config/polybar/config.ini </dev/null >/var/tmp/polybar-secondary.log 2>&1 200>&- &
else
  polybar --reload primary -c ~/.config/polybar/config.ini </dev/null >/var/tmp/polybar-primary.log 2>&1 200>&- &
fi

Afterword

In case you need more help with your BSPWM setup, feel free to contact me by email at miika@miikanissi.com. You can find the rest of my configuration in my dotfiles repository. Specifically, you can check here to see my bspwmrc at the time of writing this post and here for the associated monitor setup script.

Fast Fuzzy Finder for Vim With Fzf and Ripgrep

Tue, 19 Apr 2022 20:29:54 -0400

Fzf is a lightning fast command-line fuzzy finder that runs asynchronously and can be integrated in Vim to search for files, file contents, and much more. In order to get the most out of the fuzzy finding capabilities of fzf, we will be pairing it with ripgrep and bat. This will improve the search results and add a nice syntax highlighted preview window. With the power of fzf and ripgrep we can efficiently jump from file to file and improve our workflow.

Setting up Fzf in Vim

Fzf has an official Vim plugin that can be installed with any Vim plugin manager. We can install fzf with vim-plug by adding this to our .vimrc and by running :PlugInstall:

Plug 'junegunn/fzf', { 'do': { -> fzf#install() } }
Plug 'junegunn/fzf.vim'

Useful Fzf Commands That Work Out of the Box

Command	List
`:Files [PATH]`	Files (runs `$FZF_DEFAULT_COMMAND` if defined)
`:GFiles [OPTS]`	Git files (`git ls-files`)
`:Buffers`	Open buffers
`:Rg [PATTERN]`	rg search results (`ALT-A` to select all, `ALT-D` to deselect all)
`:Tags [QUERY]`	Tags in the project (`ctags -R`)
`:Marks`	Marks
`:Windows`	Windows
`:Snippets`	Snippets (UltiSnips)

Integrating Ripgrep With Fzf

By default, fzf uses the find command to walk through a file hierarchy to locate files based on a search criterion. However, fzf supports other similar search tools such as fd, ripgrep, or the silver searcher for creating a list of files to traverse through. My preferred search tool to use is ripgrep. Ripgrep is a fast line-oriented search tool that recursively searches the current directory for a regex pattern. Ripgrep also automatically respects rules defined in .gitignore, .ignore, and .rgignore for cleaner search results.

We can override the default fzf find command by defining FZF_DEFAULT_COMMAND in our environment. The easiest way to do this is by setting it in our .bashrc:

export FZF_DEFAULT_COMMAND='rg --files --ignore-vcs --hidden'

This command passes three options to ripgrep to make ripgrep print the output of files, including hidden files, while respecting rules set in .gitignore.

Now if we call :Files in Vim we should see a list of files based on the search results from rg --files --ignore-vcs --hidden.

We can also use ripgrep to interactively search for file contents. Fzf supports this behavior out of the box with the command :Rg.

Fzf File Previews Inside Vim

It is very helpful to have file previews enabled in order to find the right file with fzf. This can be achieved by redefining the default fzf commands in our .vimrc:

command! -bang -nargs=? -complete=dir Files
    \ call fzf#vim#files(<q-args>, fzf#vim#with_preview(), <bang>0)
command! -bang -nargs=? -complete=dir GFiles
    \ call fzf#vim#gitfiles(<q-args>, fzf#vim#with_preview(), <bang>0)
command! -bang -nargs=* Rg
    \ call fzf#vim#grep(
    \   'rg --column --line-number --no-heading --color=always --smart-case -- '.shellescape(<q-args>), 1,
    \   fzf#vim#with_preview(), <bang>0)

Now if we call :Files, :GFiles, or :Rg in vim and make our search, we can see file previews.

Syntax Highlighting

By default, fzf uses the cat command to show the file previews, but if we are mostly working on code, we might want to also see some syntax highlighting in our file previews. Luckily, fzf supports this out of the box with an external program bat. All we need to do is to install it and fzf will automatically use it.

Afterword

Overall, fzf has great performance, and it has improved my programming workflow, especially when working with big projects. If you are interested in checking out my complete Vim configuration, go to https://github.com/miikanissi/dotfiles.

Graduated as an ICT Engineer

Fri, 15 Apr 2022 20:07:43 -0400

I started my Bachelor of Engineering program in Information and Communications Technology at HAMK University of Applied Sciences in Fall 2018. As of April 14th, 2022, I am officially a graduated ICT Engineer. Despite the title of an ICT Engineer, my main focus in my studies has been programming and computer science.

My time at HAMK was great. I went from a hobbyist programmer to a professional software developer. I loved the flexibility of my studies, as I had the opportunity to take interesting classes from many of the best universities in Finland. I am especially grateful of the opportunity of remote learning towards the end of my studies, as I relocated to New York City while also working a full-time job.

My degree program has only been a starting point in my journey of learning and has given me great tools to keep improving and become a better software developer. As part of my degree I wrote a Bachelor’s Thesis on Improving Event Management Implementation on Odoo Business Management Software, which can be found online for free at https://www.theseus.fi/handle/10024/507297.

Reflections on Full Stack Open

Sun, 13 Mar 2022 12:28:42 -0400

For my last class before graduation, I decided to take a Full Stack Open course by University of Helsinki. The course serves as an introduction to modern web application development with JavaScript. The main focus is on building single page applications with ReactJS that use REST APIs built with Node.js. There is also a section about GraphQL, a modern alternative to REST APIs.

The course covers testing, configuration and environment management, and the use of MongoDB for storing the application’s data, too. There are also additional parts on Docker Containers, React Native and CI/CD.

The core curriculum consists of 5-14 ECTS credits, of which I completed 13 credits (I skipped part 13 - relational databases, since I have plenty of experience on the topic). Each credit corresponds to roughly 27 hours of work totaling 351 hours for my 13 credits, however I ended up spending roughly 200 hours on the course.

My Experience

I particularly enjoyed the practical aspect of the course - it explained the best practices of web development and introduced many helpful tools to ease the development such as linters, NPM packages and editor plugins. The course included parts on CI/CD and Docker Containers, which are tools to ease development and are practical technologies to be accustomed to.

The class had a great natural progression and most exercises were building on top of previous exercises, which meant there were a lot of refactoring and building additional features on top of pre-existing features, which mimics the development process in the real world.

A big portion of the course focused on writing tests using Jest/React Testing Library to write unit tests and using Cypress to write E2E tests. This was my first time being introduced to E2E testing, and I was surprised at how advanced the process was - Cypress is a great testing framework.

I completed the 2021 version of the course in early 2022, which meant some of the material was slightly outdated and used older versions of Node.js and React. In practice this was only a small hurdle as most version changes were well documented, and I could find an answer with a quick Google search.

Afterword

I would recommend the course to anyone with a solid programming background that has little to no experience with React/Node.js and are interested in learning the stack. Overall, the course is one of the best free online courses on modern web development.

You can browse my exercise solutions here.

If you have any questions or want to hear more about my experience with the course, you can send me an email at miika@miikanissi.com.

Qtile Window Manager

Tue, 30 Nov 2021 17:23:03 -0400

I love tinkering with different Linux window managers and desktop environments. My latest interest has been Qtile. It is a dynamic tiling window manager written and configured in Python. I chose to give Qtile a try as I mainly program in Python on a day-to-day basis and thought it was a good idea to have a window manager which uses the same language.

After a couple of weeks of use, I’m already loving the customizability and workflow. In this post, I will shortly go over my setup and share my configuration files.

My Setup

My setup is similar to what I have used in the past. I have a top bar which contains basic information such as time, date, volume, battery, system tray, workspaces and so on. The main color scheme I went with was a Gruvbox community light theme. This is a very pleasant theme on the eyes, and I’m a big fan of light color themes.

The rest of my setup is mostly the same as previously, with Vim as my main text editor. Dunts as a notification manager. LightDM as a display manager. Autorandr to hot plug my external laptop monitors. Network Manager as a network manager (duh). St as my terminal emulator and bash as a shell.

Configuration file for Qtile:

# ~/.config/qtile/config.py
# Miika Nissi, https://miikanissi.com
# Standard library imports
import os
import subprocess
from typing import List

# Qtile imports
from libqtile import bar, layout, widget, hook, qtile
from libqtile.config import Click, Drag, Group, Key, Match, Screen
from libqtile.lazy import lazy

# Third party imports
# For dynamic multiscreen, install xlib from pip
from Xlib import display

# colors
black = "#f9f5d7"
black0 = "#928374"
red = "#cc241d"
red0 = "#9d0006"
green = "#98971a"
green0 = "#79740e"
yellow = "#d79921"
yellow0 = "#b57614"
blue = "#458588"
blue0 = "#076678"
purple = "#b16286"
purple0 = "#8f3f71"
aqua = "#689d6a"
aqua0 = "#427b58"
white = "#7c6f64"
white0 = "#3c3836"
background = black
foreground = white0
soft = "#f2e5bc"

# Global variables
mod = "mod4"
terminal = "st"
browser = "brave-browser"
file_browser = "pcmanfm"
home = os.path.expanduser("~")
slash = ""
separator = slash

# Dynamic multiscreen setup
d = display.Display()
s = d.screen()
r = s.root
res = r.xrandr_get_screen_resources()._data

screen_count = 0
for output in res["outputs"]:
    mon = d.xrandr_get_output_info(output, res["config_timestamp"])._data
    if mon["num_preferred"] and mon["crtc"]:
        screen_count += 1
if screen_count == 0:
    screen_count = 1


@hook.subscribe.client_new
def transient_window(window):
    if window.window.get_wm_transient_for():
        window.floating = True


@hook.subscribe.startup_once
def autostart():
    """ Programs to start when window manager is loading """
    autostart = os.path.expanduser("~/.config/qtile/autostart.sh")
    subprocess.call([autostart])


keys = [
    # Switch between windows
    Key([mod], "h", lazy.layout.left(), desc="Move focus to left"),
    Key([mod], "l", lazy.layout.right(), desc="Move focus to right"),
    Key([mod], "j", lazy.layout.down(), desc="Move focus down"),
    Key([mod], "k", lazy.layout.up(), desc="Move focus up"),
    Key([mod], "space", lazy.layout.next(), desc="Move window focus to other window"),
    # Move windows between left/right columns or move up/down in current stack.
    # Moving out of range in Columns layout will create new column.
    Key(
        [mod, "shift"], "h", lazy.layout.shuffle_left(), desc="Move window to the left"
    ),
    Key(
        [mod, "shift"],
        "l",
        lazy.layout.shuffle_right(),
        desc="Move window to the right",
    ),
    Key([mod, "shift"], "j", lazy.layout.shuffle_down(), desc="Move window down"),
    Key([mod, "shift"], "k", lazy.layout.shuffle_up(), desc="Move window up"),
    # Grow windows. If current window is on the edge of screen and direction
    # will be to screen edge - window would shrink.
    Key([mod, "control"], "h", lazy.layout.grow_left(), desc="Grow window to the left"),
    Key(
        [mod, "control"], "l", lazy.layout.grow_right(), desc="Grow window to the right"
    ),
    Key([mod, "control"], "j", lazy.layout.grow_down(), desc="Grow window down"),
    Key([mod, "control"], "k", lazy.layout.grow_up(), desc="Grow window up"),
    Key([mod], "comma", lazy.prev_screen(), desc="Focus to the left screen"),
    Key([mod], "period", lazy.next_screen(), desc="Focus to the right screen"),
    Key([mod], "n", lazy.layout.normalize(), desc="Reset all window sizes"),
    # Toggle between split and unsplit sides of stack.
    # Split = all windows displayed
    # Unsplit = 1 window displayed, like Max layout, but still with
    # multiple stack panes
    Key(
        [mod, "shift"],
        "Return",
        lazy.layout.toggle_split(),
        desc="Toggle between split and unsplit sides of stack",
    ),
    Key([mod], "Return", lazy.spawn(terminal), desc="Launch terminal"),
    # Toggle between different layouts as defined below
    Key([mod], "Tab", lazy.next_layout(), desc="Toggle between layouts"),
    Key([mod, "shift"], "c", lazy.window.kill(), desc="Kill focused window"),
    Key([mod, "shift"], "r", lazy.reload_config(), desc="Reload the config"),
    Key(
        [mod, "shift"],
        "q",
        lazy.spawn(
            "rofi -show powermenu -modi powermenu:"
            + home
            + "/.local/bin/rofi_powermenu.sh"
        ),
        desc="Shutdown Qtile",
    ),
    Key([mod], "t", lazy.window.toggle_floating(), desc="Toggle floating window"),
    Key([mod], "f", lazy.window.toggle_fullscreen(), desc="Toggle fullscreen window"),
    # programs
    Key([mod], "d", lazy.spawn("rofi -show run"), desc="Spawn Rofi run prompt"),
    Key(
        [mod, "shift"],
        "d",
        lazy.spawn(home + "/.local/bin/rofi_passmenu.sh"),
        desc="Spawn Rofi passmenu",
    ),
    Key(
        [mod, "shift", "control"],
        "d",
        lazy.spawn(home + "/.local/bin/rofi_passmenu_otp.sh"),
        desc="Spawn Rofi passmenu one time password",
    ),
    Key(
        [mod],
        "z",
        lazy.spawn(home + "/.local/bin/rofi_dman.sh"),
        desc="Spawn Rofi device manager",
    ),
    Key(
        [mod],
        "x",
        lazy.spawn(home + "/.local/bin/rofi_killprocess.sh"),
        desc="Spawn Rofi process manager",
    ),
    Key(
        [mod],
        "q",
        lazy.spawn(home + "/.local/bin/rofi_power_menu.sh"),
        desc="Spawn Rofi power menu",
    ),
    Key(
        [mod, "shift"],
        "Print",
        lazy.spawn(home + "/.local/bin/screenrecord.sh"),
        desc="Screenrecord gif",
    ),
    Key([mod], "Print", lazy.spawn("flameshot gui"), desc="Screenshot tool"),
    Key([mod], "w", lazy.spawn(browser), desc="Launch browser"),
    Key([mod], "b", lazy.spawn(file_browser), desc="Launch file browser"),
    Key([mod], "e", lazy.spawn("geary"), desc="Launch email client"),
    Key(
        [mod],
        "s",
        lazy.spawn("signal-desktop --start-in-tray --use-tray-icon"),
        desc="Launch Signal messenger",
    ),
    Key(
        [mod],
        "m",
        lazy.spawn(terminal + " -n ncmpcpp -t ncmpcpp -e ncmpcpp"),
        desc="Launch NCMPCPP music player",
    ),
]

groups = [Group(i) for i in "123456789"]

for i in groups:
    keys.extend(
        [
            # mod1 + letter of group = switch to group
            Key(
                [mod],
                i.name,
                lazy.group[i.name].toscreen(),
                desc="Switch to group {}".format(i.name),
            ),
            # mod1 + shift + letter of group = switch to & move focused window to group
            Key(
                [mod, "shift"],
                i.name,
                lazy.window.togroup(i.name, switch_group=True),
                desc="Switch to & move focused window to group {}".format(i.name),
            ),
            # Or, use below if you prefer not to switch to that group.
            # # mod1 + shift + letter of group = move focused window to group
            # Key([mod, "shift"], i.name, lazy.window.togroup(i.name),
            #     desc="move focused window to group {}".format(i.name)),
        ]
    )

layouts = [
    layout.Columns(
        border_focus=[purple],
        border_normal=[black0],
        border_width=3,
        insert_position=1,
    ),
    layout.Max(),
]

widget_defaults = dict(
    font="Ubuntu",
    fontsize=12,
    padding=3,
    background=background,
    foreground=foreground,
)
extension_defaults = widget_defaults.copy()

caffeine = widget.GenPollText(
    update_interval=1,
    func=lambda: subprocess.check_output(
        home + "/.local/bin/statusbar/caffeine.sh"
    ).decode("utf-8"),
    mouse_callbacks={
        "Button1": lambda: qtile.cmd_spawn(
            home + "/.local/bin/statusbar/caffeine.sh --toggle"
        )
    },
    font="UbuntuNerdFont",
    fontsize=16,
    padding_right=4,
    padding_left=0,
)
powermenu = widget.TextBox(
    text="",
    foreground=red,
    padding=4,
    font="UbuntuNerdFont",
    fontsize=16,
    mouse_callbacks={
        "Button1": lambda: qtile.cmd_spawn(
            "rofi -show powermenu -modi powermenu:"
            + home
            + "/.local/bin/rofi_powermenu.sh"
        )
    },
)
volume = widget.Volume(volume_app="pavucontrol", background=soft, padding=0)
battery = widget.Battery(
    format="{char}{percent:2.0%}",
    unknown_char="",
    show_short_text=False,
    low_foreground=red,
    notify_below=10,
    padding=0,
)
mpd = widget.Mpd2(
    idle_message="idle",
    idle_format="{play_status} [{repeat}{random}{single}{consume}{updating_db}] {idle_message}",
    status_format="{play_status} [{repeat}{random}{single}{consume}{updating_db}] {artist} - {title}",
    no_connection="",
    space="",
)

screens = [
    Screen(
        top=bar.Bar(
            [
                widget.CurrentLayoutIcon(padding=3),
                widget.GroupBox(
                    highlight_method="line",
                    disable_drag=True,
                    hide_unused=True,
                    active=foreground,
                    inactive=black0,
                    block_highlight_text_color=foreground,
                    this_screen_border=purple,
                    this_current_screen_border=purple,
                    other_screen_border=black0,
                    other_current_screen_border=foreground,
                    highlight_color=[black0],
                    padding=6,
                    spacing=0,
                    margin_x=0,
                ),
                widget.WindowName(for_current_screen=True, padding=6),
                mpd,
                widget.TextBox(
                    padding=0,
                    text=separator,
                    foreground=soft,
                    fontsize=28,
                    font="UbuntuNerdFont",
                ),
                widget.TextBox(text="vol:", background=soft),
                volume,
                widget.TextBox(
                    padding=0,
                    text=separator,
                    background=soft,
                    foreground=background,
                    fontsize=28,
                    font="UbuntuNerdFont",
                ),
                widget.TextBox(text="bat:"),
                battery,
                widget.TextBox(
                    padding=0,
                    text=separator,
                    foreground=soft,
                    fontsize=28,
                    font="UbuntuNerdFont",
                ),
                widget.Clock(format="%I:%M%P %m/%d/%Y", background=soft, padding=0),
                widget.TextBox(
                    padding=0,
                    text=separator,
                    background=soft,
                    foreground=background,
                    fontsize=28,
                    font="UbuntuNerdFont",
                ),
                caffeine,
                widget.Systray(padding=2),
                powermenu,
            ],
            26,
            background=background,
        ),
    ),
]
if screen_count > 1:
    for screen in range(0, screen_count):
        screens.append(
            Screen(
                top=bar.Bar(
                    [
                        widget.CurrentLayoutIcon(padding=3),
                        widget.GroupBox(
                            highlight_method="line",
                            disable_drag=True,
                            hide_unused=True,
                            active=foreground,
                            inactive=black0,
                            block_highlight_text_color=foreground,
                            this_screen_border=purple,
                            this_current_screen_border=purple,
                            other_screen_border=black0,
                            other_current_screen_border=foreground,
                            highlight_color=[black0],
                            padding=6,
                            spacing=0,
                            margin_x=0,
                        ),
                        widget.WindowName(for_current_screen=True, padding=6),
                        widget.TextBox(
                            padding=0,
                            text=separator,
                            foreground=soft,
                            fontsize=28,
                            font="UbuntuNerdFont",
                        ),
                        widget.TextBox(text="vol:", background=soft),
                        volume,
                        widget.TextBox(
                            padding=0,
                            text=separator,
                            background=soft,
                            foreground=background,
                            fontsize=28,
                            font="UbuntuNerdFont",
                        ),
                        widget.TextBox(text="bat:"),
                        battery,
                        widget.TextBox(
                            padding=0,
                            text=separator,
                            foreground=soft,
                            fontsize=28,
                            font="UbuntuNerdFont",
                        ),
                        widget.Clock(
                            format="%I:%M%P %m/%d/%Y", background=soft, padding=0
                        ),
                        widget.TextBox(
                            padding=0,
                            text=separator,
                            background=soft,
                            foreground=background,
                            fontsize=28,
                            font="UbuntuNerdFont",
                        ),
                        caffeine,
                        widget.TextBox(),
                        powermenu,
                    ],
                    26,
                    background=background,
                ),
            ),
        )

# Drag floating layouts.
mouse = [
    Drag(
        [mod],
        "Button1",
        lazy.window.set_position_floating(),
        start=lazy.window.get_position(),
    ),
    Drag(
        [mod], "Button3", lazy.window.set_size_floating(), start=lazy.window.get_size()
    ),
    Click([mod], "Button2", lazy.window.bring_to_front()),
]

dgroups_key_binder = None
dgroups_app_rules = []
follow_mouse_focus = True
bring_front_click = False
cursor_warp = False
floating_layout = layout.Floating(
    float_rules=[
        # Run the utility of `xprop` to see the wm class and name of an X client.
        *layout.Floating.default_float_rules,
        Match(title="Quit and close tabs?"),
        Match(wm_type="utility"),
        Match(wm_type="notification"),
        Match(wm_type="toolbar"),
        Match(wm_type="splash"),
        Match(wm_type="dialog"),
        Match(wm_class="ncmpcpp"),
        Match(wm_class="Conky"),
        Match(wm_class="file_progress"),
        Match(wm_class="confirm"),
        Match(wm_class="dialog"),
        Match(wm_class="download"),
        Match(wm_class="error"),
        Match(wm_class="notification"),
        Match(wm_class="splash"),
        Match(wm_class="toolbar"),
        Match(wm_class="confirmreset"),  # gitk
        Match(wm_class="makebranch"),  # gitk
        Match(wm_class="maketag"),  # gitk
        Match(wm_class="ssh-askpass"),  # ssh-askpass
        Match(title="branchdialog"),  # gitk
        Match(title="pinentry"),  # GPG key password entry
    ]
)
auto_fullscreen = False
focus_on_window_activation = "smart"
auto_minimize = False

# Needed for some Java programs
wmname = "LG3D"
# Fixes QT apps
os.environ["QT_QPA_PLATFORMTHEME"] = "qt5ct"

This configuration will surely change in the future, and you can always find my most up-to-date setup on my GitHub.

Bachelors Thesis

Sun, 21 Nov 2021 14:40:12 -0400

For the past year, I have been working for a company that specializes in open source business management software, especially Odoo - Open Source ERP and CRM. In spring 2021 I was tasked to research Odoo’s (version 14) abilities as an Event Management System for a customer and what improvements needed to be made. I found three important features that were missing and together with my employer and the customer we decided that I could use the development of these features as my Bachelor’s thesis.

The Missing Features and Development

1. Canceling Registrations

In the core version of Odoo 14, registrants do not have the ability to cancel their own registrations - only the event manager could cancel them. This is a big inconvenience as registrants would need to contact the event manager manually in case of a cancellation. My solution was to create a portal view for the registrants to manage the state of their registrations. This portal could be accessed through a unique URL sent with the registration confirmation email.

Additionally, the event manager could define how long before the event begins the cancellations are possible. For example, the event manager could choose to close cancellations when there is less than 24 hours until the event begins.

2. Waiting List

It is common for an event management system to have a waiting list if an event is fully booked. However, Odoo 14 does not have this feature. My solution was to make a user-friendly way to sign up for a waiting list with an email notification if the event had more seats available.

The process of joining a waiting list followed the same process as registrations, with the difference that the registrant was not required to make a payment. If the event got more seats available in the waiting list, members would receive an email to confirm their seat in a first-come first-serve basis. For a paid event, this confirmation included making a payment through the system.

3. Questions

Odoo 14 has the ability to ask registrants custom questions in the registration form. These questions could either be free text questions or drop down selections, but our customer had a need for more complex registration forms. My solution was to integrate Odoo’s event management with an existing Odoo survey feature. This survey allows a more customizable way of creating complex forms, and with this integration we saved time and future maintenance cost by not creating a fully custom form creation system and instead used a pre-existing feature.

Finishing Touches

I wrote my thesis based on the project after the development process. The thesis is now published and can be viewed from a permanent address at https://urn.fi/URN:NBN:fi:amk-2021111220157.

Suckless Dwm Dmenu and St

Mon, 28 Jun 2021 21:08:01 -0400

I’ve been a fan of minimalist software for quite a while now, and I’m always looking for more simple and reliable technology. Suckless is a community of programmers who have made some great pieces of minimalist software that I recently started using. In this post, I want to showcase my setup and some thoughts.

Dwm - a Dynamic Window Manager

Dwm, like all of suckless software, has no configuration files or options. Everything is hard-coded into the source code. To customize dwm, you need to modify the source code and compile it yourself. There are no binary releases at all.

This process of modifying the source code might be intimidating, but due to the community around suckless software there are countless patches available for different needs. Here is a list of patches I’m currently using for dwm:

Actualfullscreen, allows toggling a window as full screen.
Alwayscenter, all floating windows are centered on spawn.
Attachbottom, new windows are attached to the bottom of the stack instead of top.
Autostart, run a custom bash script on dwm startup.
Colorbar, ability to change the colors of the bar for every element.
Hide vacant tags, hides all the tags not in use from the bar.
Pertag, allows each tag to have a different layout.
Stacker, move windows up/down the stack.
Staticstatus, status bar only on one monitor.
Statuscmd, ability to have clickable status bar items.
Vanitygaps, adds gaps between windows.
Xrdb, reads colors from ~/.Xresources at run time.

As you can see, I have quite a list of extra patches applied to dwm, increasing the lines of code from around 2000 to 2700. I see many of these patches as almost necessary, such as the full screen patch or the stacker patch.

Dwmblocks - a Status Bar for Dwm

Dwmblocks is a modular status bar for dwm. It is not made by suckless, but it follows the same spirit of suckless software by being source based and only 200 lines of code.

“Blocks” are shell scripts that output some information. You can then define how often or what signal is needed to run the script. For example, I have this script for my clock that runs every 30 seconds outputting the date and time. Clicking the clock opens a terminal with calcurse.

#!/bin/sh

case $BUTTON in
    1) setsid -f $TERMINAL -e calcurse ;;
esac
date "+ %Y %b %d (%a), %-I:%M%p"

Dmenu is a dynamic menu which allows you to create different prompts. By default, dmenu has a basic run prompt to launch applications.

I have also made a few scripts utilizing dmenu such as dman, which allows you to mount/unmount devices, and killprocess, which allows you to easily kill unresponsive programs.

Another useful dmenu script I found is passmenu. Passmenu allows you to get your passwords from Pass (The Standard UNIX Password Manager).

I also have applied a couple of dmenu patches:

Xresources-alt, reads colors from ~/.Xresources.
Password, allows dmenu to hide keyboard input as dots with the option -P.

St - a Simple Terminal

You’d think finding a good terminal emulator that is fast and simple would be easy. I have tried xterm, urxvt, alacritty, kitty and so on, but they either lack basic features or are too slow and complicated for no reason. However, st is a simple terminal emulator for X that works great with a few extra patches.

The patches I have applied are:

Bold is not bright, renders bold font with same color as regular font.
Scrollback, allows scrolling back and forth on the terminal.
Xresources, reads colors and other options from ~/.Xresources.

Afterword

At first, I was hesitant to use suckless software because it is source based which made it seem intimidating. But the initial learning curve was worth it. Now I have my own custom builds of these programs and everything works great. I will keep this post updated if I face any problems, or I make further changes. So far I’m more than pleased.

Configuring ESLint and Prettier for Vim With Ale

Sat, 22 May 2021 00:56:55 -0400

Recently, I wanted to set up Vim with ESLint and Prettier for JavaScript development, and it took me a surprisingly long time to find the best solution. In this post, I’m going to go over the steps needed to get your JavaScript linting and automatic fixing working inside of Vim.

Asynchronous Lint Engine (ALE) for Vim

First, we are going to need a Vim plugin to help us integrate ESLint and Prettier into Vim. Asynchronous Lint Engine(ALE) is a Vim/Neovim plugin providing on-the-fly syntax checking and automatic file formatting. It integrates with various linters and is easy to customize.

I’m not going to go into depth on all the different ways of installing VIM plugins. For the sake of this post, we’re going to use vim-plug as our plugin manager. I will assume you already have it installed according to the installation instructions.

In your vimrc add:

call plug#begin('$HOME/.vim/plugged')
Plug 'dense-analysis/ale'
call plug#end()

Running :PlugInstall in Vim will install ALE for us, and we can move on.

Installing ESLint and Prettier From NPM

Generally, I like to install all of my programs from the official repository of my Linux distribution or build them from source. In this case, we need to use npm to install prettier-eslint. Prettier-eslint combines Prettier and ESLint to format a JavaScript file.

Prettier is an opinionated code formatter (sometimes too opinionated) and you might need to follow a specific guideline provided by ESLint. Prettier-eslint first runs Prettier on a JavaScript file. After formatting, it hands the process over to ESLint, which can apply some specific changes based on ESLint rules. ESLint rules are specified in a configuration file located in ~/.eslintrc*.

To install prettier-eslint we need npm. Then we can run:

npm install -D --save-dev prettier-eslint-cli

Vim Configuration for ALE and Prettier/ESLint

Most of the heavy lifting is automatically done by prettier-eslint so our VIM configuration is pretty simple. To have ALE use prettier-eslint, we need to define it as a “fixer” in our vimrc:

let g:ale_fixers = {
    \   'javascript': ['eslint'],
    \}

Now we can run :ALEFix in our JavaScript files to format and fix our code.

We should also define ESLint as our linter for JavaScript files. This means we will see error messages on-the-fly as we work on our code.

let g:ale_linters = {
    \   'javascript': ['eslint'],
    \}

Personally, I like to have a few other configuration options for ALE. These include fixing and formatting code on save, remove code highlighting on errors, and show error and warning sings in the Vim sign column (on the left).

let g:ale_fix_on_save = 1
let g:ale_sign_error = '>>'
let g:ale_sign_warning = '--'
let g:ale_echo_msg_error_str = 'E'
let g:ale_echo_msg_warning_str = 'W'
let g:ale_echo_msg_format = '[%linter%] %s [%severity%]'
let g:ale_python_flake8_options = '--max-line-length 88 --extend-ignore=E203'

Afterword

I felt the need to write this post as most solutions I could find on search engines were outdated or unnecessarily complicated.

Notice a mistake in this post or need help setting up your JavaScript environment in Vim? Feel free to contact me via email at miika@miikanissi.com.

Git Guide for Dummies

Mon, 17 May 2021 00:00:00 -0400

This simple Git guide is satire and not meant to offend anyone. If you are a dummy or a beginner to using Git, this might actually be helpful to you and work as a cheat sheet (I sometimes visit this post when I forget a command).

`git clone`

Get my shit.

`git push`

Send my shit.

`git add <filename>`

Track my new shit.

`git add --patch`

Let me choose the new shit to track.

`git commit`

This shit is good for now.

`git pull`

Get the new shit.

`git checkout -b <branch name>`

I’m going to work on my shit over here for now.

`git checkout <branch name>`

I’m going back to this shit.

`git merge <branch name>`

Mix that shit with this shit.

`git checkout --theirs`

That shit is better than this shit, fuck this.

`git checkout --ours`

This shit is better than that shit, fuck that.

`git commit --amend`

I need to fix my shit.

`git log`

Let’s look at this shit.

`git status`

I need to know my shit.

`git rm <filename>`

I don’t need this shit.

`git commit --fixup=<commit hash> (or --squash)`

Here’s some new shit to fix some old shit. I’ll rebase it later.

`git rebase -i [--autosquash] <old commit>`

Are you dumb?
1. No, let’s clean this shit up.
2. Yes, just fuck my shit up.

That’s It

Knowing how to use these Git commands is mostly all you need for a good Git workflow. Happy programming.

Email Setup With Mbsync + Mu4e

Sun, 18 Apr 2021 00:00:00 -0400

Mu4e is a powerful email client for Emacs. It is rather simple to use and having your mail in Emacs is the best thing ever. I recently started using mu4e as my email client, and it turns out configuring it is a bit of a hassle. This post works as a guide on setting up mu4e email client for Emacs with mbsync to sync email.

Pass To Securely Store Your Passwords

To be able to store your email password securely, you need to set up GPG and pass. I have previously made a post on configuring pass so take a look at it before you proceed.

Every time you want to add a new email, make sure you add a pass entry for it first.

Setting up Mbsync

To fetch and sync email from the mail server using IMAP, you need to use isync/mbsync. First, you need to install this on your system with your package manager.

For Arch Linux:

sudo pacman -S isync

For Ubuntu 20.04+:

sudo apt install isync

Mbsync configuration file is located at ~/.mbsyncrc. A typical configuration looks as follows (replace the content between <,> with values provided by your email provider):

IMAPAccount <account>
Host <imap.host.tld>
Port <993>
User <email username>
PassCmd "pass <account>"
SSLType IMAPS
CertificateFile /etc/ssl/certs/ca-certificates.crt

IMAPStore <account>-remote
Account <account>

MaildirStore <account>-local
SubFolders Verbatim
Path ~/Mail/<account>/
Inbox ~/Mail/<account>/Inbox
Trash ~/Mail/<account>/Trash

Channel <account>
Far :<account>-remote:
Near :<account>-local:
;; Patterns are the names of your mail folders. You can also use * for all of your mail folders.
Patterns INBOX "Sent Items" Drafts Trash Spam?
SyncState *
Create Both
Expunge Both
CopyArrivalDate yes
Sync All

Note: If you have 2FA enabled, you might need to use an app specific password. Confirm this from your email provider.

Note2: See ArchWiki article about isync for more configuration options and tips.

Make sure to create the root folder used in the mbsync configuration:

mkdir -p ~/Mail/<account>

If everything was configured correctly, you can now sync your email to your local folder:

mbsybc <account>

Mu4e

Mu4e, the Emacs mail client, comes included with the mu, mail indexing program. You can get mu directly from their GitHub page or various package managers.

For Arch Linux with AUR helper yay:

yay -S mu

For Ubuntu 20.04+:

sudo apt install maildir-utils

Mu4e configuration for Emacs (replace content between <,> with your own values):

(use-package mu4e
  :ensure nil
  :defer 5
  :load-path "/usr/share/emacs/site-lisp/mue4/"
  :config
  (require 'org-mu4e)

  ;; refresh mbsync every 10 minutes
  (setq mu4e-update-interval (* 10 60))
  (setq mu4e-get-mail-command "mbsync -a")
  (setq mu4e-maildir "<maildir>")
  ;; use pass to store passwords
  ;; file auth looks for is ~/.password-store/<smtp.host.tld>:<port>/<name>
  (auth-source-pass-enable)
  (setq auth-sources '(password-store))
  (setq auth-source-debug t)
  (setq auth-source-do-cache nil)
  ;; no reply to self
  (setq mu4e-compose-dont-reply-to-self t)
  (setq mu4e-compose-keep-self-cc nil)
  ;; moving messages renames files to avoid errors
  (setq mu4e-change-filenames-when-moving t)
  ;; Configure the function to use for sending mail
  (setq message-send-mail-function 'smtpmail-send-it)
  ;; Display options
  (setq mu4e-view-show-images t)
  (setq mu4e-view-show-addresses 't)
  ;; Composing mail
  (setq mu4e-compose-dont-reply-to-self t)
  ;; don't keep message buffers around
  (setq message-kill-buffer-on-exit t)
  ;; Don't ask for a 'context' upon opening mu4e
  (setq mu4e-context-policy 'pick-first)
  ;; Don't ask to quit... why is this the default?
  (setq mu4e-confirm-quit nil)

  ;; Set up contexts for email accounts
  (setq mu4e-contexts
        (list
         (make-mu4e-context
          :name "<mail account name>"
          :match-func
      (lambda (msg)
            (when msg
              (string-prefix-p "/<mail account dir>" (mu4e-message-field msg :maildir))))
          :vars `((user-mail-address . "<mail address>")
                  (user-full-name    . "<mail full name>")
                  (smtpmail-smtp-server  . "<smtp.host.tld>")
                  (smtpmail-smtp-service . "<smtp port>")
                  (smtpmail-stream-type  . ssl)
                  (smtpmail-smtp-user . "<email username>")
                  (mu4e-compose-signature . "<email signature>")
                  (mu4e-drafts-folder  . "<mail account dir>/<draft dir>")
                  (mu4e-sent-folder  . "<mail account dir>/<sent dir>")
                  (mu4e-refile-folder  . "<mail account dir>/<archive dir>")
                  (mu4e-trash-folder  . "<mail account dir>/<trash dir>")))))

  (setq m/mu4e-inbox-query
        "(maildir:/<mail account dir>/<inbox dir>) AND flag:unread")
  (defun m/go-to-inbox ()
    (interactive)
    (mu4e-headers-search m/mu4e-inbox-query))
  ;; start mu4e
  (mu4e t))

Note: Mu4e looks for your password file in ~/.password-store/<smtp.host.tld>:<port>/<mail account name>

This is a rather basic configuration for one email account. For my full configuration you can check my dotfiles on GitHub.

Afterword

If everything was configured correctly, you should now be able to read and send email from Emacs using mu4e. If you need any help with your configuration, don’t hesitate to contact me with email: miika@miikanissi.com.

Website With Emacs

Sun, 21 Mar 2021 00:00:00 -0400

NOTE: I am no longer using this setup for my website.

In this post, I will briefly go over my setup of using Emacs Org-mode for managing and publishing my blog website.

Workflow

I write all of my posts and static sites in Org-mode within Emacs and when I want to update my site I run a custom publishing function which exports Org-mode files into HTML. My custom function also creates a sitemap for my blog posts and an RSS feed.

Setup

My setup is in my Emacs configuration file, which you can find in its entirety from my GitHub.

File Structure

root
├── org
│   ├── about.org
│   ├── blog
│   │   └── post1.org
│   ├── css
│   │   └── site.css
│   ├── html
│   │   ├── html_head.html
│   │   ├── html_postamble.html
│   │   └── html_preamble.html
│   ├── img
│   │   ├── favicon.ico
│   │   └── miika.jpg
│   ├── index.org
│   ├── rss.org
│   └── sitemap.org
└── www
    ├── about.html
    ├── blog
    │   └── post1.html
    ├── css
    │   └── site.css
    ├── img
    │   ├── favicon.ico
    │   └── miika.jpg
    ├── index.html
    ├── rss.xml
    └── sitemap.html

9 directories, 19 files

Sitemap / Blog Index

These functions are used to format a sitemap to have a date for each entry.

(defun m/org-publish-org-sitemap (title list)
  "Sitemap generation function."
  (concat "#+TITLE: Sitemap\n\n"
          (org-list-to-subtree list)))

(defun m/org-publish-org-sitemap-format-entry (entry style project)
  (cond ((not (directory-name-p entry))
         (let* ((date (org-publish-find-date entry project)))
           (format "%s - [[file:%s][%s]]"
                   (format-time-string "%F" date) entry
                   (org-publish-find-title entry project))))
        ((eq style 'tree)
         ;; Return only last subdir.
         (file-name-nondirectory (directory-file-name entry)))
        (t entry)))

RSS Feed

RSS-feed generation is done with the ox-rss package, but it requires some additional customization for my needs.

(defun m/org-rss-publish-to-rss (plist filename pub-dir)
  "Publish RSS with PLIST, only when FILENAME is 'rss.org'.
PUB-DIR is when the output will be placed."
  (if (equal "rss.org" (file-name-nondirectory filename))
      (org-rss-publish-to-rss plist filename pub-dir)))

(defun m/format-rss-feed (title list)
  "Generate RSS feed, as a string.
TITLE is the title of the RSS feed.  LIST is an internal
representation for the files to include, as returned by
`org-list-to-lisp'.  PROJECT is the current project."
  (concat "#+TITLE: " title "\n\n"
          (org-list-to-subtree list 1 '(:icount "" :istart ""))))

(defun m/format-rss-feed-entry (entry style project)
  "Format ENTRY for the RSS feed.
ENTRY is a file name.  STYLE is either 'list' or 'tree'.
PROJECT is the current project."
  (cond ((not (directory-name-p entry))
         (let* ((file (org-publish--expand-file-name entry project))
                (title (org-publish-find-title entry project))
                (date (format-time-string "%Y-%m-%d"
                (org-publish-find-date entry project)))
                (link (concat (file-name-sans-extension entry) ".html")))
          (with-temp-buffer
            (insert (format "* %s\n" title))
            (org-set-property "RSS_PERMALINK" link)
            (org-set-property "PUBDATE" date)
            (insert-file-contents file)
            (buffer-string))))
        ((eq style 'tree)
         ;; Return only last subdir.
         (file-name-nondirectory (directory-file-name entry)))
        (t entry)))

Project Spec for Org-publish

This spec defines the directory structure and exporting options for org-publish

(defun m/get-publish-project-spec ()
    "Return project settings for use with `org-publish-project-alist'."
    (let* ((website-root (file-name-as-directory
                          "~/miikanissi.com"))
           (website-org (file-name-as-directory
                         (concat website-root "org")))
           (website-www (file-name-as-directory
                         (concat website-root "www")))
           (website-org-img (file-name-as-directory
                             (concat website-org "img")))
           (website-www-img (file-name-as-directory
                             (concat website-www "img")))
           (website-org-css (file-name-as-directory
                             (concat website-org "css")))
           (website-www-css (file-name-as-directory
                             (concat website-www "css")))
           (website-org-html (file-name-as-directory
                              (concat website-org "html")))
           (website-org-blog (file-name-as-directory
                               (concat website-org "blog")))
           (get-content (lambda (x)
                          (with-temp-buffer
                            (insert-file-contents (concat website-org-html
                                                          x))
                            (buffer-string))))
           (website-html-head (funcall get-content "html_head.html"))
           (website-html-preamble (funcall get-content "html_preamble.html"))
           (website-html-postamble (funcall get-content "html_postamble.html")))
        `(("org"
           :base-directory ,website-org
           :base-extension "org"
           :recursive t
           :exclude "rss\\.org\\|sitemap\\.org"
           :publishing-directory ,website-www
           :publishing-function org-html-publish-to-html
           :author "Miika Nissi"
           :email "miika@miikanissi.com"
           :with-title t
           :description "This is my personal website: a place where you can read and learn about technology related subjects."
           :keywords "Miika Nissi, blog, resume, technology, programming"
           :section-numbers nil
           :headline-levels 4
           :language en
           :with-toc nil
           :with-date t
           :with-email t
           :with-statistics-cookies nil
           :with-todo-keywords nil
           :auto-sitemap t
           :sitemap-sort-files anti-chronologically
           :sitemap-format-entry m/org-publish-org-sitemap-format-entry
           :html-head-include-default-style nil
           :html-head-include-scripts nil
           :htmlized-source t
           :html-doctype "html5"
           :html-html5-fancy t
           :html-head ,website-html-head
           :html-preamble ,website-html-preamble
           :html-postamble ,website-html-postamble)
          ("images"
           :base-directory ,website-org-img
           :base-extension "png\\|jpg\\|gif\\|svg\\|ico"
           :recursive t
           :publishing-directory ,website-www-img
           :publishing-function org-publish-attachment)
          ("css"
           :base-directory ,website-org-css
           :base-extension "css"
           :publishing-directory ,website-www-css
           :publishing-function org-publish-attachment)
          ("rss"
           :base-directory ,website-org
           :base-extension "org"
           :exclude "rss\\.org\\|index\\.org\\|about\\.org\\|sitemap\\.org"
           :recursive t
           :publishing-directory ,website-www
           :publishing-function m/org-rss-publish-to-rss
           :title "Miika's Blog"
           :description "This feed contains blog posts from Miika Nissi. Topics ranging from lifestyle to technology."
           :author "Miika Nissi"
           :html-link-use-abs-url t
           :html-link-home "https://miikanissi.com/"
           :with-broken-link t
           :with-toc nil
           :rss-image-url "https://miikanissi.com/img/favicon.ico"
           :with-date t
           :with-author t
           :creator "Miika Nissi"
           :with-description t
           :auto-sitemap t
           :sitemap-filename "rss.org"
           :sitemap-title "Miika's blog"
           :sitemap-style list
           :sitemap-sort-files anti-chronologically
           :sitemap-function m/format-rss-feed
           :sitemap-format-entry m/format-rss-feed-entry)
          ("miikanissi.com" :components ("org" "images" "css" "rss")))))

Project Publishing Function

The website is updated when calling m/publish-website, which only publishes newly modified files. When used with additional arguments, a full update can be forced: (m/publish-website "miikanissi.com" t).

(defun m/publish-website (&optional project force)
    "Publish personal website."
    (interactive)
    (unless project (setq project "miikanissi.com"))
    (let ((org-publish-project-alist (m/get-publish-project-spec))
          (org-export-date-timestamp-format "%Y-%m-%d")
          (org-todo-keywords '((sequence "TODO" "REVIEW" "|"
                                         "DONE" "DEFERRED" "ABANDONED"))))
      (org-publish-project project force))
    (templated-html-create-sitemap-xml "~/miikanissi.com/www/sitemap.xml" "~/miikanissi.com/www" "https://miikanissi.com/"))

Afterword

My setup is constantly changing, but for now I’m happy with the setup I’ve built. For the latest updates, you can check my GitHub.

Pass: The Standard Unix Password Manager

Thu, 04 Feb 2021 00:00:00 -0400

Pass is a simple password manager that strictly follows the Unix philosophy. It simply provides a directory structure of GPG encrypted files containing passwords and other information for each password. In this post, I will go over how to initialize Pass and different ways of interacting with it.

Setup

If you don’t have a GPG key, we need to generate one with:

gpg --full-generate-key

In order to use this key with Pass, run the command:

gpg --list-secret-keys --keyid-format LONG

This will show details of your key. Look for a line that looks something like this:

sec    rsa2048/0D2740AEE2FAEA2B 2021-01-07 [SC]

We need to copy the string after the line rsa2048/ until the date. With this, we can create our password store by running:

pass init "0d2740AEE2FAEA2B"

Now we have created our password store and can start adding passwords to it by doing:

pass insert <CATEGORY>/<SUBCATEGORY>/<NAME>

For example, to add an entry for an email address we would enter:

pass insert email/gmail/miika@gmail.com

This will prompt us to enter a password and the contents will be saved into a GPG protected file with our key. The location of this file will be in ~/.password-store/email/gmail/miika@gmail.com.

In order to decrypt this file and get its content, we can run:

pass email/gmail/miika@gmail.com

This will echo the output in the terminal.

Now we have a GPG encrypted file that contains your password. To add other information to this file such as a username and URI, we can run:

pass edit email/gmail/miika@gmail.com

Since this is just a GPG encrypted file, you are free to edit it to your liking, but the preferred organizational scheme used by the author of Pass looks like this:

Yw|ZSNH!}z"6{ym9pI
URL: *.amazon.com/*
Username: AmazonianChicken@example.com
Secret Question 1: What is your childhood best friend's most bizarre superhero fantasy? Oh god, Amazon, it's too awful to say...
Phone Support PIN #: 84719

Pass-OTP

Pass-otp is an extension for pass that allows for two-factor authentication support. To add an OTP secret to our account, we can run:

pass otp append -a -s email/gmail/miika@gmail.com

You can also get the OTP secret from a QR code by running:

zbarimg -q --raw qrcode.png | pass otp insert totp-secret

Frontends to Pass

To interact with pass outside the terminal, there are a couple helpful extensions. Since I use dmenu there is a dmenu script that comes with Pass. You can run it with passmenu as long as you have dmenu installed.

There is also an Emacs package called password-store which allows you to copy passwords to your kill-ring from Emacs. I use both of these frontends depending on my workflow.

Afterword

To learn more about Pass, you can check the official website at . They also have a list of other extensions and conversion tools to migrate from other password managers.

Managing Dotfiles With Git

Sun, 20 Dec 2020 00:00:00 -0400

Dotfiles are user specific application configuration files. Traditionally, they are stored as files whose filename starts with a dot, hence the term dotfiles. It is common to track these dotfiles with a version control system such as Git for easy portability between systems. In this post, I will show my way of tracking and managing these dotfiles.

Setup

For easy management of all dotfiles in the home directory, I like to create a git repository which has a work tree in the $HOME directory but a separate git directory in $HOME/dotfiles. That way, this git repository won’t get in the way of other potential Git repositories you might have in your home directory or in subdirectories.

To do this, you first need to create a directory dotfiles in your home directory:

mkdir dotfiles

Next, we create an alias, so we don’t need to type this long command every time. To do this, paste the following:

echo "alias dotfiles=\"git --work-tree $HOME --git-dir $HOME/dotfiles\"" \
>> ~/.bashrc && bash

We can now initialize the dotfiles directory as a git directory inside of it by running:

dotfiles init

To add a remote origin for this repository, we run:

dotfiles remote add -t \* -f origin <url-of-the-remote-repository>

If this new remote repository already has dotfiles that you want to sync with your system, you can simply checkout the branch you want. For example dotfiles checkout master.

That is all you need to do to create this git repository, and you can do all the normal git specific commands but you just need to use dotfiles instead of git as the prefix. To add a new file to be tracked by this repository, you would do:

dotfiles add <filename> ;\
dotfiles commit -m "<Your commit message>" ;\
dotfiles push origin master

Since your home directory has a lot of files, you would most likely want to ignore all untracked files when checking the status of this git repository. For that, we can run:

dotfiles config --local status.showUntrackedFiles no

Afterword

This is how I personally manage my own dotfiles and found this solution easier than other solutions such as symlinks, rsync, Ansible and so on. If you are interested in my own personal dotfiles you can check them out on my GitHub.