(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.
(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.
| var connect = require('multilevel-connect'); | |
| var db = connect('password@host:port'); | |
| db.createReadStream() | |
| .on('data', function(kv){ | |
| console.log(JSON.stringify(kv)); | |
| }) | |
| .on('end', function(){ | |
| process.exit(0) |
| { | |
| // The block has begun, we're in a new block scope. The TDZ for the "a" binding has begun | |
| var f = function() { | |
| // 2. Because f() is evaluated before `a` is actually declared, | |
| // an exception will be thrown indicating to the author that | |
| // `a` is not yet defined. | |
| console.log(a); | |
| }; | |
I wrote this guide because after getting my CubieBoard 1 I followed the Arch Linux ARM instructions and was suprised to be left with a system that albeit working, had missing RAM and no fbconsole at all.
This guide gets Arch Linux ARM into your 1GB Cubieboard 1 with the minimum functionality one would expect. It is not intended to be an all encompassing document, focusing instead on saving your time having to read through the forum to get functionality that otherwise every other Linux distribution brings out of box.
You will have to adjust these instructions if you have a 512M Cubieboard.
At a minimum, you need to create the first partition on an SD card to store the bootloader files and kernel uImage. For the root filesystem you can choose to use either a second partition on the SD card, USB or SATA. This guide however only covers SD. Replace instances of /dev/mmcblkX with the appropriate device name registered on your system.
| "use strict"; | |
| function processNodeList(list, target) { | |
| list.forEach(function(node) { | |
| processNode(node, target); | |
| }); | |
| } | |
| function processNode(node, target) { | |
| switch (node._type) { |
| So, I'm gonna make a book. It's gonna start off as a document in sphinx-doc, so I just | |
| publish as a flat file HTML, and then maybe figure out funding it if there's enough | |
| interest in the output. The subject of the book would be an open source project that can | |
| be completely viewed on it's own, and the idea is that the book would go through the | |
| technologies involved, the decision process, and how it's all structured together to | |
| build a self sufficient Frontend client. | |
| Key ideas are a structure of modular components, that means when you end up with shit | |
| going out of date, you don't have to change everything to adapt. Give new technology |
I've known people at nodejitsu for years, since before the company even existed. I still consider many of them friends. That said, somebody over there has lost their mind.
Trademarks are an important part of open source. They protect the integrity of the trust that is built by any project. A classic example of why this is the case is Firefox. Suppose that a malware producer takes the Firefox codebase, which is free and open source, packages up their malware with it and then releases it as "Firefox". Then they buy search advertising and suddenly their bad and malicious version of Firefox is the first result on search engines across the web. This is clearly a bad thing for Firefox and open source everywhere, but what can Mozilla do to protect their community of users?
They can't enforce a software license since the use is permitted under the Mozilla Public License. They can, however, enforce on these hypothetical bad actors using their trademark on the word "Fi
[In reply to https://news.ycombinator.com/item?id=7219005]
Here's the history, hope it helps.
I wrote the original version of the npm registry in a day or two on top of CouchDB. I built it quickly and didn't think much about scale.
Isaacs continued to improve and maintain that code. At one point he even wrote up an open standard for generic js package registries for CommonJS but they didn't seem to care (they were too busy arguing about promises).
At the time I wrote the initial code I was employed at CouchOne and we had a small CouchDB hosting platform operated by Jason Smith which is where we ran the registry free of charge. Later on, after CouchOne was aquired by Membase and became Couchbase, it decided to break off the hosting company and give/sell it to Jason Smith, which became IrisCouch.
There was a [great article][1] about how react implements it's virtual DOM. There are some really interesting ideas in there but they are deeply buried in the implementation of the React framework.
However, it's possible to implement just the virtual DOM and diff algorithm on it's own as a set of independent modules.
| // module a | |
| b = require("./b") | |
| module.exports = function() { | |
| console.log("I'm in module a") | |
| } | |
| b() |