Inspired by:
See Also:
Inspired by:
See Also:
| #!/bin/bash | |
| # IMPORTANT: Don't forget to logout from your Apple ID in the settings before running it! | |
| # IMPORTANT: You will need to run this script from Recovery. In fact, macOS Catalina brings read-only filesystem which prevent this script from working from the main OS. | |
| # This script needs to be run from the volume you wish to use. | |
| # E.g. run it like this: cd /Volumes/Macintosh\ HD && sh /Volumes/Macintosh\ HD/Users/sabri/Desktop/disable.sh | |
| # WARNING: It might disable things that you may not like. Please double check the services in the TODISABLE vars. | |
| # Get active services: launchctl list | grep -v "\-\t0" | |
| # Find a service: grep -lR [service] /System/Library/Launch* /Library/Launch* ~/Library/LaunchAgents |
| // stub for typescript | |
| declare function BigInt(n: number): number | |
| abstract class Trampoline<A> { | |
| abstract map<B>(ab: (a: A) => B): Trampoline<B> | |
| abstract flatMap<B>(ab: (a: A) => Trampoline<B>): Trampoline<B> | |
| zip<B>(tb: Trampoline<B>): Trampoline<[A, B]> { | |
| const ta = this | |
| return ta.flatMap(a => tb.map(b => [a, b] as [A, B])) |
Since it has come up a few times, I thought I’d write up some of the basic ideas around domain modeling in Clojure, and how they relate to keyword names and Specs. Firmly grasping these concepts will help us all write code that is simpler, cleaner, and easier to understand.
Clojure is a data-oriented language: we’re all familiar with maps, vectors, sets, keywords, etc. However, while data is good, not all data is equally good. It’s still possible to write “bad” data in Clojure.
“Good” data is well defined and easy to read; there is never any ambiguity about what a given data structure represents. Messy data has inconsistent structure, and overloaded keys that can mean different things in different contexts. Good data represents domain entities and a logical model; bad data represents whatever was convenient for the programmer at a given moment. Good data stands on its own, and can be reasoned about without any other knowledge of the codebase; bad data is deeply and tightly coupled to specific generating and
# $LOCAL_IP: 'localhost' or machine from local network
# $LOCAL_PORT: open port on local machine
# $REMOTE_IP: remote localhost or IP from remote network
# $REMOTE_PORT: open port on remote site
# Forward Tunnel: map port from remote machine/network on local machine
ssh -L $LOCAL_PORT:$REMOTE_IP:$REMOTE_PORT $USER@$SERVER
# Reverse Tunnel: make local port accessable to remote machine| """Ansible dict filters.""" | |
| # Make coding more python3-ish | |
| from __future__ import (absolute_import, division, print_function) | |
| __metaclass__ = type | |
| from ansible.errors import AnsibleError |
| const I = x => x | |
| const K = x => y => x | |
| const A = f => x => f (x) | |
| const T = x => f => f (x) | |
| const W = f => x => f (x) (x) | |
| const C = f => y => x => f (x) (y) | |
| const B = f => g => x => f (g (x)) | |
| const S = f => g => x => f (x) (g (x)) | |
| const S_ = f => g => x => f (g (x)) (x) | |
| const S2 = f => g => h => x => f (g (x)) (h (x)) |
| <?php | |
| $formHtml = <<<'HTML' | |
| <form action="%s" method="post"> | |
| <label for="email">Email:</label> | |
| <input | |
| type="email" | |
| id="email" | |
| name="email" | |
| value="" |
| * { | |
| font-size: 12pt; | |
| font-family: monospace; | |
| font-weight: normal; | |
| font-style: normal; | |
| text-decoration: none; | |
| color: black; | |
| cursor: default; | |
| } |