- View: Also called a "template", a file that contains markup (like HTML) and optionally additional instructions on how to generate snippets of HTML, such as text interpolation, loops, conditionals, includes, and so on.
- View engine: Also called a "template library" or "templater", ie. a library that implements view functionality, and potentially also a custom language for specifying it (like Pug does).
- HTML templater: A template library that's designed specifically for generating HTML. It understands document structure and thus can provide useful advanced tools like mixins, as well as more secure output escaping (since it can determine the right escaping approach from the context in which a value is used), but it also means that the templater is not useful for anything other than HTML.
- String-based templater: A template library that implements templating logic, but that has no understanding of the content it is generating - it simply concatenates together strings, potenti
| package main | |
| import ( | |
| "compress/gzip" | |
| "fmt" | |
| "io/ioutil" | |
| "net/http" | |
| "time" | |
| "encoding/json" |
| // check version | |
| node -v || node --version | |
| // list locally installed versions of node | |
| nvm ls | |
| // list remove available versions of node | |
| nvm ls-remote | |
| // install specific version of node |
Based on Abdelrahman Omran PWA presentation, and Google PWA Codelab
This is a working example on how to store CryptoKeys locally in your browser. We are able to save the objects, without serializing them. This means we can keep them not exportable (which might be more secure?? not sure what attack vectors this prevents).
To try out this example, first make sure you are in a browser that has support for async...await and indexedDB (latest chrome canary with chrome://flags "Enable Experimental Javascript" works). Load some page and copy and paste this code into the console. Then call encryptDataSaveKey(). This will create a private/public key pair and encrypted some random data with the private key. Then save both of them. Now reload the page, copy in the code, and run loadKeyDecryptData(). It will load the keys and encrypted data and decrypt it. You should see the same data logged both times.
| import requests | |
| import base64 | |
| from tqdm import tqdm | |
| master_json_url = 'https://178skyfiregce-a.akamaihd.net/exp=1474107106~acl=%2F142089577%2F%2A~hmac=0d9becc441fc5385462d53bf59cf019c0184690862f49b414e9a2f1c5bafbe0d/142089577/video/426274424,426274425,426274423,426274422/master.json?base64_init=1' | |
| base_url = master_json_url[:master_json_url.rfind('/', 0, -26) + 1] | |
| resp = requests.get(master_json_url) | |
| content = resp.json() |
Paprika doesn't have their API documented, so this is me reverse-engineering it from an Android device
Use it at your own risk! You might end up worse than before. Backup everything beforehand. Twice.
If you have the Messages app setup in multiple Macs with the same Apple ID you may end up with iMessages (or SMS) scattered around all of these Macs. This is because after a certain time the new iMessages (or SMS) recevied will cease to push to devices afer a certain time has elapsed. Thus, if a computer has been offline for some period of time it won't get the new iMessages.
Each Messages instance stores the information in a SQLite database, to consolidate all these databases run the script below. This is where the Messages app stores the SQLite database under ~/Library/Messages, the folder contents will look like as follows:
- chat.db
| // Created by Matthew Johnson on 5/28/16. | |
| // Copyright © 2016 Anandabits LLC. All rights reserved. | |
| // | |
| // This is a minimalist implementation of a responder chain in pure Swift. | |
| // | |
| // It is not intended to demonstrate the best way to | |
| // implement event processing in Swift. | |
| // | |
| // The intent is to show how little code is necessary to acheive behavior | |
| // similar to Cocoa's responder chain in pure Swift. |