espenbjorkeng

// 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

joepie91

You don't need a blockchain.

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

mquandalle

Thoughts on a Meteor ORM

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.

The problem

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/

staltz

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

---

This tutorial as a series of videos

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.

---

wemeetagain

// [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]

howlingblast

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'

gavinandresen

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.