The following are the commands that I create on a per-project basis within the
repo-env folder as referenced in the workflow described here.
A few notes:
/path/to/repo-env/ with the appropriate absolute path to your repo-env<> is a variable to be replaced<prefix>/$ARGUMENTS is written that way because I tend to prefix my branches with my name
| // vscode-keybindings for navigation with I/J/K/L and additional functionality with surrounding characters | |
| // Place your key bindings in this file to overwrite the defaults | |
| // ALT + I/J/K/L: up/left/down/right | |
| // ALT + SHIFT + I/J/K/L: mark text up/left/down/right | |
| // CTRL + J/L: send cursor to start/end of line | |
| // CTRL + ALT + J/L: send cursor to start/end of word | |
| // CTRL + ALT + U/O: send cursor to "wordPartLeft"/"wordPartRight" | |
| // CTRL + ALT + SHIFT + U/O: mark from cursor to "wordPartLeft"/"wordPartRight" | |
| // CTRL + ALT + Y: got to declaration |
If you're reading this, you probably suggested to somebody that a particular technical problem could be solved with a blockchain.
Blockchains aren't a desirable thing; they're defined by having trustless consensus, which necessarily has to involve some form of costly signaling to work; that's what prevents attacks like sybil attacks.
In other words: blockchains must be expensive to operate, to work effectively. This makes it a last-resort solution, when you truly have no other options available for solving your problem; in almost every case you want a cheaper and less complex solution than a blockchain.
In particular, if your usecase is commercial, then you do not need or want trustless consensus. This especially includes usecases like supply chain tracking, ticketing, and so on. The whole *p
While we're approaching the 1.0 release of Meteor, the need and interest in additional databases support (other than MongoDB) has risen consequently. Thus, SQL support is the second most requested feature on the official meteor roadmap (after server-side rendering) and there have been various demands on the forums about supporting Redis (also on the roadmap), RethinkDB, LevelDB, Neo4J, ElasticSearch, Mysql/MariaDB, PosgreSQL, SQLite and some other. More importantly the Meteor community has started to work on atmosphere packages that bring support for these databases and it appeared to be a very difficult task – most projects were abandoned.
What makes the integration of a new database a lot harder in Meteor than in most other web frameworks (including “full stack” JavaScript frameworks like Derby or Sails) lies in the third [principle of Meteor](http://docs.meteor.com/
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
| // [AMT] - Withdraw AMT from contract | |
| // tracks 'employee' withdrawal time, amount, and contract balance starting at storage[500] | |
| if tx.value < 100 * block.basefee: | |
| stop | |
| if tx.sender == CONTRACT_CREATOR: | |
| // if a withdrawal amount is set, attempt withdrawl | |
| if tx.data[0] > 0: | |
| WITHDRAWAL_LOG_INDEX = contract.storage[499] + 500 | |
| LAST_WITHDRAWAL_TIME = contract.storage[WITHDRAWAL_LOG_INDEX] |
| Function::property = (prop, desc) -> | |
| Object.defineProperty @prototype, prop, desc | |
| class Person | |
| constructor: (@firstName, @lastName) -> | |
| @property 'fullName', | |
| get: -> "#{@firstName} #{@lastName}" | |
| set: (name) -> [@firstName, @lastName] = name.split ' ' | |
| p = new Person 'Leroy', 'Jenkins' |
Thumbnail sketch: Two-factor (Yubikey or Google Authenticator) protected wallets
Hardware:
Computer. Shared-secret authenticator (Yubikey/Google Authenticator/etc). Server (possibly shared with millions of other users).
Motivating use case setup:
User creates a split (2-of-2 multisig) wallet on the computer and server. Keys must be securely backed up to protect against loss. GUI to be determined, but there will be some type of "Use Authenticator" checkbox specified at setup.