| #!/bin/bash | |
| # | |
| # Mac OS Test Script | |
| # | |
| # 1. Download to your computer as "check.sh" | |
| # 2. Run in terminal using "bash check.sh" | |
| # | |
| set -e | |
| check () { |
| [ | |
| { | |
| "code": "us-east-1", | |
| "region": "US East", | |
| "city": "Virginia", | |
| "lat": 38.9940541, | |
| "long": -77.4524237, | |
| "country": "US" | |
| }, | |
| { |
| const Corestore = require('corestore') | |
| const Networker = require('@corestore/networker') | |
| const { mkdir } = require('fs/promises') | |
| let index = 0 | |
| async function create () { | |
| index += 1 | |
| const dir = `.tmp/${index}` | |
| await mkdir(dir, { recursive: true }) | |
| const store = new Corestore(dir) |
In DAT, append-only logs addressable by a key are called hypercores. When you copy one such log to another computer and write to it, there are suddenly two logs in two different locations. The new location being a fork of the first log. Both logs can be found under the same ID, making it impossible to distinguish them from another.
DAT mitigates this by making every log "single-writer". Only with a secret writeKey you can append data to the log. By convention that secret is
A primer on i18n in Node.js by Martin Heidegger on the night between Dec. 24 and Dec. 25 2015
Many ways lead to the metaphorical rome to achieve i18n and by extension l10n in Node.js. Several packages such as i18next, i18n or node-gettext provide quite accepted implementations for internationalization, yahoo also has pushed the game and published formatjs. But even with those packages at hand i18n can be tricky! Target platform, workflow, human resources, user experience, revisioning - all of that plays an important role when choosing how to setup internationalization for a system. To give a deeper insight in the matter I collected my understanding of i18n in thi
| 'use strict' | |
| const setOp = require('unordered-set') | |
| module.exports = { | |
| add: (count, objs) => { | |
| const set = [] | |
| for (var i = 0; i < count; i++) { | |
| setOp.add(set, objs[i]) | |
| setOp.add(set, objs[i]) | |
| } | |
| return set |
How do I write the following JavaScript in Typescript most efficiently?
sample.js does a fairly simplified example for a code with the logic: "if callback, then
callback, else promise" in add and a logAndAdd method reuses add, so the result of logAndAdd will also
be either a callback or a promise, depending on the input.
test.js makes sure that this is supposed to work
sample.d.ts is how I assume the .d.ts should look like
sample.ts is not working but shows how I thought TypeScript could work neatly.
I hereby claim:
To claim this, I am signing this object:
| function partArray (...parts) { | |
| let lengths = parts.map(part => part.length) | |
| let length = lengths.reduce((total, length) => total + length) | |
| function* iterator () { | |
| for (const part of parts) | |
| for (const value of part) yield value | |
| } | |
| function item (index) { | |
| let partIndex = 0 | |
| for (const part of parts) { |
| time,cpu[user]#avg,cpu[user]#min,cpu[user]#max,cpu[system]#avg,cpu[system]#min,cpu[system]#max,mem[heapUsed]#avg,mem[heapUsed]#min,mem[heapUsed]#max,mem[heapTotal]#avg,mem[heapTotal]#min,mem[heapTotal]#max,mem[external]#avg,mem[external]#min,mem[external]#max | |
| 1513914518233, 78273,78273,78273,23573,23573,23573,5583596,5329040,5838152,10854400,10854400,10854400,558976,439592,678360 | |
| 1513914520381.644, 61037.47537077804,61037.47537077804,61037.47537077804,23573,23573,23573,7570791.859881992,7168906.021724596,7898616.114693746,10854400,10854400,10854400,1522872.917892116,1416024.60562031,1889588.4111456308 | |
| 1513914522528.9185, 48683.45425623419,48683.45425623419,48683.45425623419,23573,23573,23573,8585283.686068054,8419800.250697419,8931602.671535378,10854400,10854400,10854400,2458086.628234829,2394709.239230188,2883538.4351940444 | |
| 1513914524676.8794, 39999.763262061286,39999.763262061286,39999.763262061286,23573,23573,23573,9220846.7495376,9108108.058582326,9425541.758640196,10854400,10854400,10854400,3383111.35641 |