openssl req -x509 -newkey rsa:4096 -sha256 -keyout example.key -out example.crt -subj "/CN=example.com" -days 3650 -passout pass:foobar
openssl x509 -x509toreq -in example.crt -out example.csr -signkey example.key -passin pass:foobar
openssl req -x509 -newkey rsa:4096 -sha256 -keyout example.key -out example.crt -subj "/CN=example.com" -days 3650 -passout pass:foobar
openssl x509 -x509toreq -in example.crt -out example.csr -signkey example.key -passin pass:foobar
ssh-keygen -t rsa -b 4096 -m PEM -f jwtRS256.key | |
# Don't add passphrase | |
openssl rsa -in jwtRS256.key -pubout -outform PEM -out jwtRS256.key.pub | |
cat jwtRS256.key | |
cat jwtRS256.key.pub |
{ | |
"version": "0.2.0", | |
"configurations": [ | |
{ | |
"name": "Node Inspector", | |
"type": "node", | |
"request": "launch", | |
"args": ["${workspaceRoot}/src/service.ts"], | |
"runtimeArgs": ["-r", "ts-node/register"], | |
"cwd": "${workspaceRoot}", |
/** | |
* Fancy ID generator that creates 20-character string identifiers with the following properties: | |
* | |
* 1. They're based on timestamp so that they sort *after* any existing ids. | |
* 2. They contain 72-bits of random data after the timestamp so that IDs won't collide with other clients' IDs. | |
* 3. They sort *lexicographically* (so the timestamp is converted to characters that will sort properly). | |
* 4. They're monotonically increasing. Even if you generate more than one in the same timestamp, the | |
* latter ones will sort after the former ones. We do this by using the previous random bits | |
* but "incrementing" them by 1 (only in the case of a timestamp collision). | |
*/ |
I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.
I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real
The computer driven markets for instruments like stocks and exchange traded stock options, have transformed finance and the flow of capital. These markets are enabled by order matching engines (and the infrastructure that supports this software). Before computer trading networks and matching engines, stocks where traded on cavernous exchange floors and transaction costs where high. When electronic trading fully matured, floor traders were a fading anachronism and transaction costs had been reduced to pennies a share in many cases. Electronic trading could not exist without advanced network infrastructure, but without the software matching engines no shares would change hands. The computer trading networks, the matching engine software has also created a concentrated nexus of potential failure. Failures in these systems have increased as the frequency and volume on the electronic networks has increased. The position of order matching engines in the trading infrastructure makes these systems o
The repository for the assignment is public and Github does not allow the creation of private forks for public repositories.
The correct way of creating a private frok by duplicating the repo is documented here.
For this assignment the commands are:
git clone --bare git@github.com:usi-systems/easytrace.git