Joi Custom Validtion
Adds a custom validation function to execute arbitrary code
Set a null
value for any data type regardless of whats given. I used this in a nested if/when statement to only trigger under certain conditions based on other key values.
Here's the gist:
/* | |
about:config | |
toolkit.legacyUserProfileCustomizations.stylesheets: true | |
create chrome directory in default release path, found in about:profiles | |
/Users/$user/Library/Application Support/Firefox/Profiles/xxxxx.default-release/chrome | |
copy userChrome.css and userContent.css to | |
/Users/$user/Library/Application Support/Firefox/Profiles/xxxxx.default-release/chrome | |
*/ | |
@-moz-document url(chrome://browser/content/browser.xhtml) { |
it looks like the iterm2 upgrade to 3.4.4 reset keybindings. Added the following to .zshrc
brought back the history search.
bindkey -v
bindkey '^R' history-incremental-search-backward
information about a similiar issue: https://bbs.archlinux.org/viewtopic.php?id=52173
#!/usr/bin/env bash | |
INI_FILE=~/.aws/credentials | |
while IFS=' = ' read key value | |
do | |
if [[ $key == \[*] ]]; then | |
section=$key | |
elif [[ $value ]] && [[ $section == '[default]' ]]; then | |
if [[ $key == 'aws_access_key_id' ]]; then |
This error happened when I was running the latest Postgres Docker image 13.1 and trying to run a migration script that used pg_dump
version 9.6.
UPDATE well, maybe the verion mismatch was the issue. the script had pg_dump
wrapped in { pg_dump ...} >> dev/null
. The shell (sh
) the script ran in exited early and the migration "terminated".
terminating connection due to administrator command
Problem
I have two Github accounts: oanhnn (personal) and superman (for work). I want to use both accounts on same computer (without typing password everytime, when doing git push or pull).
Solution
Use ssh keys and define host aliases in ssh config file (each alias for an account).
How to?
collapsible markdown?
CLICK ME
yes, even hidden code blocks!
print("hello world!")
Peer Review
One of the ways I've grown as programmer is by applying suggestions given to me in peer reviews. I've often learned more by feedback given in these reviews than any google or stackoverflow search could have taught.
Unless there is a misunderstanding of the intent of the code, most of the time, the suggestions should be taken to heart. The suggestions are made to help support future maintenance, make the code easier to understand, and almost always a general improvement to the final product. It is very, very rare for a suggestion to be made based purely on an arbitrary point of view made solely for the sake of commenting.
When suggestions are made for changes to my work, it provides me an opportunity to take a second look at my work and attempt to make the work better. Often times, these suggestions are usable in any future work I do. Now the reviewer doesn't need to continue to make the same suggestions with each review. This makes their job much easier - and mine to - because I no longer get
merge, squash, all commits of the feature-branch
into the current branch.
git merge --squash feature-branch
git commit