After watching Bryan Cantrill's presentation on [Running Aground: Debugging Docker in Production][aground] I got all excited (and strangely nostalgic) about the possibility of core-dumping server-side Python apps whenever they go awry. This would theoretically allow me to fully inspect the state of the program at the point it exploded, rather than relying solely on the information of a stack trace.
root@artemis:~# curl -d "client_id={ID}.apps.googleusercontent.com&scope=https://www.googleapis.com/auth/calendar" https://accounts.google.com/o/oauth2/device/code | |
{ | |
"device_code" : {DEVICE_CODE}, | |
"user_code" : {USER_CODE}, | |
"verification_url" : "http://www.google.com/device", | |
"expires_in" : 1800, | |
"interval" : 5 | |
} | |
root@artemis:~#curl -d "client_id={ID}.apps.googleusercontent.com&client_secret={SECRET}&code={DEVICE_CODE}&grant_type=http://oauth.net/grant_type/device/1.0" https://accounts.google.com/o/oauth2/token |
MIT License | |
Copyright (c) [spuder] 2022 | |
Permission is hereby granted, free of charge, to any person obtaining a copy | |
of this software and associated documentation files (the "Software"), to deal | |
in the Software without restriction, including without limitation the rights | |
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell | |
copies of the Software, and to permit persons to whom the Software is | |
furnished to do so, subject to the following conditions: |
In this quick walkthough you'll learn how to create a separate branch in your repo to house your screenshots and demo gifs for use in your master's readme.
In order to prevent any loss of work it is best to clone the repo in a separate location to complete this task.
Create a new branch in your repo by using git checkout --orphan assets
from itertools import * | |
from operator import * | |
convertValue, convertHouse = {'A': 1, '2': 2, '3': 3, '4': 4, '5': 5, '6': 6, '7': 7, '8': 8, '9': 9, 'T': 10, 'J': 11, 'Q': 12, 'K': 13}, {'D': 0, 'C': 1, 'H': 2, 'S': 3} | |
def addcard(n, h): | |
if len(h) <= 1 and filter(lambda x: x[0] != 0, h) == 0: h.append((0, n)) | |
else: | |
for c in h: | |
if c[0] == 2 and c[1][0][1] == n[1] and (convertValue[c[1][0][0]] == convertValue[n[0]]+1 or convertValue[c[1][2][0]] == convertValue[n[0]]-1): | |
h.append((3, c[1] + [n])) | |
h.remove(c) |
# /etc/NetworkManager/conf.d/30-randomize-mac-address.conf | |
# REQUIRES NETWORK MANAGER >= 1.4.1 (Ubuntu Zesty and above) | |
# Thanks to https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ | |
# This randomize your MAC address for *new* connections | |
# Be sure to change your existing (saved) connections in | |
# /etc/NetworkManager/system-connections/* |
# All of your normal .gdbinit commands, functions, and setup tasks | |
# Update GDB's Python paths with the `sys.path` values of the local Python installation, | |
# whether that is brew'ed Python, a virtualenv, or another system python. | |
# Convert GDB to interpret in Python | |
python | |
import os,subprocess,sys | |
# Execute a Python using the user's shell and pull out the sys.path (for site-packages) | |
paths = subprocess.check_output('python -c "import os,sys;print(os.linesep.join(sys.path).strip())"',shell=True).decode("utf-8").split() |
JavaScript warnings are these messages being displayed in yellow or red in your JavaScript console or terminal. They make no sense at all in general but they are a good indication of the health of your app. The points below will give you a general idea of how many warnings you should expect in your app:
-
0 warnings: the app is not working at all
-
5 warnings: app is probably starting but crashing soon after - try to find why it crashes. You'd think you could read the warnings to learn why it doesn't work, but that's not what warnings are for.
-
50 warnings: That's the soft spot - most likely everything's running smoothly