Farhood FeryET

Convert Rust books to EPUB (incl. The Rust Programming Language)

The following steps work for all the HTML learning materials on the Learn Rust page:

Click on the "Print this book" icon in the top right corner.
"Cancel" print popup.
Press F12.
Copy, paste, and run the contents of ebookFormatPreparation.js into your browser's console.
Save the modified HTML file.

Naming guidelines

1. Syntax

1.1 Be consistent

Consistency in naming makes reading and memory retrieval much, much easier. Conversely, changing rules and mixing conventions are very confusing and significantly increase cognitive load. Follow language, company, and project conventions for names, even if you don't like them.

1.2 Follow conventions

Enable PipeWire on Ubuntu 22.04

This guide is only for original Ubuntu out-of-the-box packages. If you have added a custom PPA like pipewire-debian, you might get into conflicts.

Ubuntu 22.04 has PipeWire partially installed and enabled as it's used by browsers (WebRTC) for recoding the screeen under Wayland. We can enable remaining parts and use PipeWire for audio and Bluetooth instead of PulseAudio.

Starting from WirePlumber version 0.4.8 automatic Bluetooth profile switching (e.g. switching from A2DP to HSP/HFP when an application needs microphone access) is supported. Jammy (22.04) repos provide exactly version 0.4.8. So, we're good.

Based on Debian Wiki, but simplified for Ubuntu 22.04.

A case for `pytest` in PyTorch

This is a short post about why I think it would be beneficial for PyTorch to not only use pytest as test runner, but also rely on the other features it provides.

Disclaimer

My experience with the PyTorch test suite is limited as of now. Thus, it might very well be that my view on things is too naive. In that case I'm happy to hear about examples where and adoption of pytest would make a use case significantly harder or outright impossible.

Setup

Test a Local Jenkins Instance on MacOS: Download, Setup, and Run Groovy Scripts Locally

About

There are many ways to test Jenkins...

Jenkins Pipeline Unit is great but it's generally recommended to keep all of your logic with stages and not get too crazy with custom Groovy in your pipeline. Though, it's a great option if you have a very advanced use-case and want to make sure your code is reliable.

The Replay Pipeline Run Option is awesome if you want to verify a quick change or iterate quickly on a previously setup pipeline. But it only allows for altering Jenkinsfile Code and runs against the production Jenkins Instance.

In most of deep learning projects, the training scripts always start with lines to load in data, which can easily take a handful minutes. Only after data ready can start testing my buggy code. It is so frustratingly often that I wait for ten minutes just to find I made a stupid typo, then I have to restart and wait for another ten minutes hoping no other typos are made.

In order to make my life easy, I devote lots of effort to reduce the overhead of I/O loading. Here I list some useful tricks I found and hope they also save you some time.

use Numpy Memmap to load array and say goodbye to HDF5.

I used to relay on HDF5 to read/write data, especially when loading only sub-part of all data. Yet that was before I realized how fast and charming Numpy Memmapfile is. In short, Memmapfile does not load in the whole array at open, and only later "lazily" load in the parts that are required for real operations.

Sometimes I may want to copy the full array to memory at once, as it makes later operations

CNs are important!!! -days 3650

Make PEM containig a public key certificate and its associated private key

openssl req -newkey rsa:2048 -new -x509 -days 3650 -nodes -subj '/C=US/ST=Massachusetts/L=Bedford/O=Personal/OU=Personal/[email protected]/CN=localhost' -out mongodb-cert.crt -keyout mongodb-cert.key

cat mongodb-cert.key mongodb-cert.crt > mongodb.pem

	build-container:
	stage: build
	image:
	name: moby/buildkit:rootless
	entrypoint: [ "sh", "-c" ]
	variables:
	BUILDKITD_FLAGS: --oci-worker-no-process-sandbox
	before_script:
	- \|
	mkdir ~/.docker

	I ran into the battle of running all of my VMs and the host node under a single public IP address. Luckily, the host is just pure Debian, and ships with iptables.

	What needs to be done is essentially to run all the VMs on a private internal network. Outbound internet access is done via NAT. Inbound access is via port forwarding.

	Network configuration

	Here’s how it’s done:

	Create a virtual interface that serves as the gateway for your VMs:

	#!/usr/bin/env python
	# -- coding:UTF-8 --

	import torch
	import torch.nn as nn
	import torch.nn.init as init


	def weight_init(m):
	'''