## Garage Door Notification | |
- id: '1588906118469' | |
alias: 'Notification: Colin''s Stuff: Garage door left open' | |
description: '' | |
trigger: | |
- entity_id: cover.garage_door | |
for: 00:10:00 | |
platform: state | |
to: open | |
- entity_id: cover.garage_door |
"""WARNING: not thoroughly tested and does not support full translation | |
between the two libraries. | |
Uses a pydantic root_validator to init the marshmallow schema. It attempts | |
to map marshmallow field types to pydantic field types as well, but not all | |
field types are supported. | |
You can either use the pydantic_from_marshmallow function that does all of | |
the above or just subclass MarshmallowModel and manually define your pydantic | |
fields/types/etc. |
- Make sure the isort extension is installed in VSCode
The latest VSCode update brought the requirement to use a python environment 3.8+ for isort:
2025-04-24 13:28:29.888 [info] No interpreter found from setting isort.interpreter
This guide provides instructions for an Arch Linux installation featuring full-disk encryption via LVM on LUKS and an encrypted boot partition (GRUB) for UEFI systems.
Following the main installation are further instructions to harden against Evil Maid attacks via UEFI Secure Boot custom key enrollment and self-signed kernel and bootloader.
You will find most of this information pulled from the Arch Wiki and other resources linked thereof.
Note: The system was installed on an NVMe SSD, substitute /dev/nvme0nX
with /dev/sdX
or your device as needed.
#!/bin/bash | |
set -euo pipefail | |
$REPO_DIR=~/devel | |
repos="1password bitwarden dashlane lastpass opvault passwordbox roboform stickypassword truekey zoho-vault" | |
# pull all repos | |
( | |
for repo in $repos; do | |
echo $repo |
I noticed myself passing around similar copies of the same git description to friends and coworkers enough times that I finally decided to write it up for a wider audience, though mostly so I would only have to do it one last time.
First off, this recommendation is for novice git users, particularly those who are coming from a CVS or Subversion background.
This workflow is based on the `Branching workflow`_ described in the `Pro Git`_ book (which I recommend that you find some time to read). In my experience, I've found that the distributed model just doesn't make sense in a corporate environment where people want there to be a single canonical origin repository.
*This is a work in progress. It's currently divided up into two sections, one describing what I hope is an easy walkthrough of recommended workflows, the other delving into much more detail about how git allows you to some of the more interes