| int main() | |
| { | |
| printf("hello world"); | |
| } |
| # See examples here: https://twitter.com/martinsohndk/status/1783470845119152340 | |
| # Add the below to your PowerShell profile | |
| # 1. In PowerShell, run: Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope CurrentUser -Force | |
| # 2. In PowerShell, run: if(!(Test-Path $PROFILE)){New-Item $PROFILE -ItemType File -Force}; notepad.exe $PROFILE | |
| # 3. Add the function to your PowerShell profile | |
| # 4. (Optional) Change the default behaviour from Clipboard to some other in 'DefaultParameterSetName' | |
| # 5. Start a new PowerShell instance | |
| # 6. Export JSON from BloodHound | |
| # 7. Convert the JSON with 'ConvertFrom-BHJSON' or the alias 'cfb' |
| blueprint: | |
| name: Low battery level detection & notification for all battery sensors | |
| description: Regularly test all sensors with 'battery' device-class for crossing | |
| a certain battery level threshold and if so execute an action. | |
| domain: automation | |
| input: | |
| threshold: | |
| name: Battery warning level threshold | |
| description: Battery sensors below threshold are assumed to be low-battery (as | |
| well as binary battery sensors with value 'on'). |
| void main() { | |
| final email1 = Email.maybeFrom("frank@moreno"); | |
| final email2 = Email.maybeFrom("frank@moreno.com"); | |
| print(email1); | |
| print(email2); | |
| } | |
| bool isValidEmail(String email) { | |
| // Regular expression to validate the format of an email |
To determine the trend, use moving averages, channel S/R, and price highs/lows.
A good starter to determine trend is to use the 200ma. You need to see higher highs and higher lows, even on your trade timeframe. For example, if there are higher highs on the 1h and 1d, but on the 1m you're seeing lower highs, don't trade until you do see at least one.
This gist contains some simple scripts that enable control over Snap's automatic updates.
| Windows Registry Editor Version 5.00 | |
| [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Search] | |
| "BingSearchEnabled"=dword:00000000 | |
| "AllowSearchToUseLocation"=dword:00000000 | |
| "CortanaConsent"=dword:00000000 | |
| [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windows Search] | |
| "AllowCortana"=dword:00000000 | |
| "DisableWebSearch"=dword:00000001 |
| module.exports = { | |
| 'extends': 'google', | |
| 'parserOptions': { | |
| 'ecmaVersion': 6, | |
| }, | |
| 'rules': { | |
| // https://eslint.org/docs/rules/array-bracket-spacing | |
| 'array-bracket-spacing': ['error', 'never'], |
This logging setup configures Structlog to output pretty logs in development, and JSON log lines in production.
Then, you can use Structlog loggers or standard logging loggers, and they both will be processed by the Structlog pipeline (see the hello() endpoint for reference). That way any log generated by your dependencies will also be processed and enriched, even if they know nothing about Structlog!
Requests are assigned a correlation ID with the asgi-correlation-id middleware (either captured from incoming request or generated on the fly).
All logs are linked to the correlation ID, and to the Datadog trace/span if instrumented.
This data "global to the request" is stored in context vars, and automatically added to all logs produced during the request thanks to Structlog.
You can add to these "global local variables" at any point in an endpoint with `structlog.contextvars.bind_contextvars(custom
