Skip to content

Instantly share code, notes, and snippets.

View iexa's full-sized avatar
💭
yorkie = lambda woof, bark: {bark: woof}

CsabaK iexa

💭
yorkie = lambda woof, bark: {bark: woof}
View GitHub Profile
@iexa
iexa / devbox-install.ps1
Last active April 23, 2023 05:01 — forked from christophwille/cw-devbox-install.ps1
Windows devbox chocolatey install base (nice ideas - probably better to use built-in winget though)
# Run in elevated PS
# Reboot required
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
# Store:
# WSL, Ubuntu, DevToys, Power BI
# EarTrumpet, Screentogif, ShareX, Photoscape X, Inkscape, RSS Bandit, Surface, WhatsApp
# Install: Office, Visual Studio, SQL Server Developer Edition, https://aka.ms/windbg/download
@iexa
iexa / test-md5.sh
Last active October 31, 2022 05:00
Test a QuickSFV file on OSX with md5 and pv for progress-bar
#!/bin/bash
# use cat md5-file | ./test-md5.sh
while IFS='' read -r line || [[ -n "$line" ]]; do
if [[ $line = *";"* ]]; then
continue
fi
path=${line#* \*}
path=${path%$'\r'}
path=${path/\\//}
@iexa
iexa / generate_docker_cert.sh
Created July 29, 2022 18:02 — forked from bradrydzewski/generate_docker_cert.sh
Generate trusted CA certificates for running Docker with HTTPS
#!/bin/bash
#
# Generates client and server certificates used to enable HTTPS
# remote authentication to a Docker daemon.
#
# See http://docs.docker.com/articles/https/
#
# To start the Docker Daemon:
#
# sudo docker -d \
@iexa
iexa / System Design.md
Created May 23, 2020 05:09 — forked from vasanthk/System Design.md
System Design Cheatsheet

System Design Cheatsheet

Picking the right architecture = Picking the right battles + Managing trade-offs

Basic Steps

  1. Clarify and agree on the scope of the system
  • User cases (description of sequences of events that, taken together, lead to a system doing something useful)
    • Who is going to use it?
    • How are they going to use it?
@iexa
iexa / Architecture.md
Created March 26, 2020 11:49 — forked from evancz/Architecture.md
Ideas and guidelines for architecting larger applications in Elm to be modular and extensible

Architecture in Elm

This document is a collection of concepts and strategies to make large Elm projects modular and extensible.

We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp. You will probably merge a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:

  1. There is a single source of truth. Traditional approaches force you to write a decent amount of custom and error prone code to synchronize state between many different stateful components. (The state of this widget needs to be synced with the application state, which needs to be synced with some other widget, etc.) By placing all of your state in one location, you eliminate an entire class of bugs in which two components get into inconsistent states. We also think yo