I had just built a custom RGB LED strip (WS2812B) out of 126 LEDs and an ESP8266 running WLED. I wanted to set it up for screen ambience. I wasn't real happy with the default LED zone options in Prismatik Lightpack and couldn't get it just right. So I made a script to automate creating zones out of my display dimensions and how many LEDs are assigned on each side.
(Original comment from scrumplex)
I was able to migrate my Docker Compose deployment. An issue I ran into was that file paths in the database were relative to immich's working directory, meaning that everything was prefixed with upload/
. I was able to remedy this by replacing upload/
with my mediaLocation
(which is also what the UPLOAD_LOCATION
variable from my Compose deployment pointed to).
Note
This is what worked for my installation that is a few years old. I am not sure if newer installations behave differently. Some facts about my Docker Compose installation:
- The database is called
immich
- The database user is called
immich
What do you consider boilerplate? Is all code boilerplate? Are humans boilerplate?
Anyways, I found a stupid way to generate a whole GraphQL schema on the fly based on a dictionary of query name to source and Strawberry models. This was used in a Strawberry + FastAPI + SQLAlchemy API project.
You essentially define a mapping for your queries. Specify the query name, and which ORM or source class/model goes to the GraphQL model equivalent. The logic will then create a new Query class object, iterate over the mapping items defined above, then generate a binding with the query name, model, and GraphQL schema associated. This binding is also dynamically generated by altering the query function's signature on runtime which contains the shared, boilerplate logic between all queries.
{ pkgs ? import <nixpkgs> {} }: | |
pkgs.mkShell { | |
nativeBuildInputs = with pkgs; [ | |
clang | |
cmake | |
ninja | |
pkg-config | |
gtk3 |
#!/bin/bash | |
# If you do not have ssh keys for root, remove all -i flag and $REMOTE_ROOT_KEYS instances from the script | |
REMOTE= # IP/hostname of remote target | |
REMOTE_ROOT_KEYS= # path to id_rsa of root user on remote target | |
LIGOLO_AGENT= # path to agent binary | |
LIGOLO_PROXY= # path to proxy binary | |
CURRENT_USER=$(whoami) | |
echo "[L] Uploading agent to remote..." |
class OpenWeatherModel(object): | |
__slots__ = "_json", "cod", "message", "base", "weather", "main", "name", "wind", "sys", "cod", "temp", "feels_like", "temp_min", \ | |
"temp_max", "pressure", "humidity", "speed", "deg", "gust", "sunrise", "sunset", "country", "timezone", \ | |
"visibility" | |
def __init__(self, **kwargs): | |
self._json = kwargs | |
for key in kwargs: | |
if key in self.__slots__: |
If on Linux/Mac OS Discord
# example commands
sudo mv $XDG_RUNTIME_DIR/discord-ipc-0 ./discord-ipc-0 # backup original socket
sudo socat -t100 -x -v UNIX-LISTEN:$XDG_RUNTIME_DIR/discord-ipc-0,mode=777,reuseaddr,fork UNIX-CONNECT:$(pwd)/discord-ipc-0
socat opens a bidirectional tunnel that will forward message to and from these two sockets.
-v
will print debug message to stdout, allowing you to read the raw hex data traffic
[NO]
= Does not work
[NO ?]
= Did not have good results, but still testing
[?]
= Still testing
1. [NO]
Searched for GH repos hosting EFIs for T450s setups. One here Following instructions as of 10/18/2021 resulted in OpenCore booting a black screen.
2. [NO ?]
Attempting to follow the guide here mentioned in an issue in above repo. MacOS Catalina in VMs run extremely slow.
Following and using the ISO in this guide:
- VirtualBox 6.26 - Extremely slow
- VirtualBox 6.20 - Extremely slow
I hereby claim:
- I am v3ntus on github.
- I am 3xcalibur (https://keybase.io/3xcalibur) on keybase.
- I have a public key ASAZ2usIZ6kvkPSWq6inILrBU3G7M2D_NeOlcIcjI-xT0Qo
To claim this, I am signing this object: