Nikola: How to Deploy Compiled Webpages to a Different Git Repository

Last updated on November 18, 2018

Nikola is one of the most popular static website generators. It compiles source files into final publishable webpages offline and then uploads those files to a web host. Compared to dynamic websites such as those powered by PHP or Ruby on Rails, static websites offer better security and faster page loading.

Nikola provides some utilities to ease the deployment procedure (i.e., uploading compiled webpages), especially for deploying as GitHub pages. Unfortunately, Nikola does not (and its team does not plan to) provide a direct way to deploy the compiled webpages to a git repository that is different from the one that hosts the source files. This is often useful when you want to hide the source files in a private git repository and leave the git repository that hosts the compiled webpages public. Luckily, Nikola provides customizable deploying commands. Assuming output is the directory where the compiled webpages are located, change the value of DEPLOY_COMMANDS using the following in conf.py (replace me@example.com with your email address, https://xuhdev@github.com/xuhdev/xuhdev.github.io.git with your designated git repository on GitHub/GitLab/BitBucket/etc., and master with your designated branch):

DEPLOY_COMMANDS = {
'default': [
"cd output && git init && git config user.email me@example.com && touch .nojekyll && git add .",
"cd output && git commit -a -m 'Nikola'",
"cd output && git push -f https://xuhdev@github.com/xuhdev/xuhdev.github.io.git master",
]
}


Now running nikola deploy should deploy the compiled webpages to your designated git repository and branch.

Technology is not Everything: Non-Technical Aspects to Consider for Open Source Projects

Last updated on November 21, 2018

Open source software, also known as free and open source software (FOSS), free, libre, and open source software (FLOSS), and free software, has become more and more popular these days. When starting a new open source software project, we developers tend to think mostly on the technical side of this project, e.g., what programming languages and frameworks to use, how to design the architecture of the software, what platforms to target at, etc. We not only think, we actually think about these really carefully: We look around for advice, struggle in our mind, and, sometimes, even after years, we still argue that we should rewrite the software in a different programming language. On the other hand, we often take the non-technical side too light without much thinking: We use a specific source code hosting service simply because everyone else uses it, we use a specific license simply because this is the only license that we are able to read through once and (vaguely) understand, etc. These decisions, however, will heavily affect the style, the advancement，or even the survival of our open source software projects.

This post aims at draw developers' attention to non-technical aspects of open source software projects. We will have a brief overview of some non-technical aspects that can be important in open source software projects (while more aspects and details can be further discussed in the future).

Swap Training and Test Data During Cross-Validation in scikit-learn

Last updated on October 11, 2018

Scikit-learn is a well known Python machine learning library. It provides various utilities for machine learning, including those for cross-validation. In a standard $$K$$-fold cross-validation, the data are split into $$K$$ subsets (with equal size). There are $$K$$ rounds of training and testing. In each round, one subset is used as test data and all other subsets are used as training data. Under this setup, as long as $$K > 2$$, there are always more training data than test data in each round of the cross-validation. Whilst this is desirable in most cases, in some machine learning applications, it is more desirable to have training data less than test data. For example, in graph embedding, each node in the network has a vector representation and labels. When running cross-validation, it is more desirable to use a smaller number of nodes as training data than the number of nodes as test data, since this better mimics the real-world scenario in terms of the amount of available training data (e.g., here). In scikit-learn, we can achieve this by swapping training and test data.

Creating Multiple-Choice Exams with Answering Boxes Using LaTeX

For a multiple-choice exam, to ease the grading procedure, it is often preferred to ask students to write their answers collectively in an answer sheet with their choices of answers filled in boxes. However, LaTeX, in particular the exam document class, does not directly provide the feature to automatically generate such boxes. In this post, we will let LaTeX to automatically generate these answering boxes, and with correct answers filled in when the answers document class option is turned on. The effects are displayed below, with correct answers shown and not shown, respectively. Their respective PDF files are also available: Without answers; with answers.

Use HTTP Clients with SOCKS Proxies (or SSH Tunnels) on GNU/Linux

Last updated on July 30, 2020

On GNU/Linux, it is easy to create SOCKS proxies using programs such as ssh or tor. However, many applications on GNU/Linux, such as LibreOffice and genymotion (up to the date on which this post is written), can be configured to directly use HTTP proxies (or web proxies), but not SOCKS proxies. In this post, we will use privoxy, a non-cache web proxy, to enable these applications to use SOCKS proxies.

Enable Auto Completion for pip in Zsh

Pip is a package management system for installing and managing Python software packages. To enable auto completion for pip in zsh, the documentation of pip suggests adding the following line to ~/.zshrc:

eval "pip completion --zsh"

However, merely having this line would not enable auto completion for pip3. To enable auto completion for pip3 as well, add the following line after the line above:

compctl -K _pip_completion pip3

A ~/.inputrc for Humans

Last updated on January 22, 2020

A Russian translation of this post is available here.

~/.inputrc is the user configuration file of GNU readline (), which provides customizable command line user interfaces for many important interactive programs, such as Bash and Python interactive shell. However, many of its useful features are disabled by default. In this post, we will walk through a decent ~/.inputrc file to release the power of readline.

Enable Natural Scrolling for Trackpads Using libinput

Last updated on October 28, 2018

Libinput is a library to handle input devices in Wayland and X.Org. It can be used as a drop-in replacement for evdev and synaptics in X.Org, and it is supported by a wide range of desktop environments, including GNOME and Xfce. In this post, we will see how to enable natural scrolling for trackpads using libinput. We will also leave mouses alone, i.e., no natural scrolling for mouses.

First, we need to know the name of the trackpad to enable natural scrolling for. This can be easily known by executing xinput --list. My output includes the following:

⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ bcm5974                                   id=13   [slave  pointer  (2)]


It is easy to see that my trackpad is bcm5974.

Send Git Patches Using GUI Email Clients

Git is a popular version control system that manages many impacting open source projects. Many of these projects, such as Linux kernel, zsh, GNU Emacs, etc. require patches and pull requests to be sent to their mailing lists. This can usually be done via git send-email or git imap-send, which, however, often takes a large amount of configuration and headaches for many people to make it work for the first time. Here, I propose a new approach to send git patches via email with GUI email clients, such as Thunderbird, Evolution, Claws Mail and Apple Mail.

Parallelize make by Default

Last updated on December 13, 2016

The make utility is an standard utility on POSIX systems (GNU/Linux, macOS, etc.) that update files derived from other files, such as compiling source files to their binary forms. It is widely supported and used across different fields such as organizing and building C/C++/Fortran projects, building Sphinx documentation, etc.

The most popular implementation of the make utility is probably GNU make, which is usually the default make program on various GNU/Linux distributions. (On macOS, the version of the default GNU make is pretty old. Please consult Install and Use GNU Command Line Tools on macOS/OS X for a newer version.) It adds one very important feature besides the standard make specification: parallelization. The command line option -j can be used to specify the maximum number of jobs that it is allowed to run simultaneously. However, it is quite annoying to type up this option every time when using it—we want a setting such that the CPU can be fully utilized by default. To achieve this goal, add the following lines to your ~/.bashrc if you use bash or ~/.zshrc if you use zsh:

# set MAKEFLAGS
if type nproc &>/dev/null; then   # GNU/Linux
export MAKEFLAGS="$MAKEFLAGS -j$(($(nproc)-1))" elif type sysctl -n hw.ncpu &>/dev/null; then # macOS, FreeBSD export MAKEFLAGS="$MAKEFLAGS -j$(($(sysctl -n hw.ncpu)-1))"
fi

The code above sets the envrionmental variable MAKEFLAGS, which specifies the command line arguments of any invoked make subprocesses. It is set such that the maximum number of jobs that is allowed to be run simultaneously is equal to the number of available CPU cores minus 1. In this way, the hardware is more or less fully utilized when using make, with one CPU core left for other potential tasks on the system.