I write Node.js libraries, and I want logging. Why is this so problematic?
Note, I am despairing about how library authors log stuff not how application builders decide on a logging framework.
Hopefully this document can become a spec or feature list for code I will write some day.
Sent this to the [CouchDB users list][email] just now; duplicated here for others to see or comment
Hi, all. Sorry to be distant from the community recently. No excuse.
I thought I might share December stats from one of Apache CouchDB's most well-known deployments and killer apps: the Node.js npm registry.
Hi, all.
Encouraged by my successful experiment with a Node.js view server, I am now working on a branch, nodejs_couchdb, with the following properties:
Phase 1: Dependency on a "couchjs" executable which you install via npm install couchjs
| // Service all /_couchdb/* requests for CouchDB | |
| // | |
| module.exports = handle_http | |
| function handle_http(req, res) { | |
| res.writeHead(200, 'OK') | |
| res.end('Hello to CouchDB!\n') | |
| } |
| ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAugw9qNFQfuzPdkjYYJX5/27o9zQGEgQ04b/iM541WL/Pjey4lkVUSk0eVjVq69PunIZjDGPR/4hBzdTxKznwvHtvT8Lgk/PKnqCf3u23vm/n0uvZ2a8HHAM06VTsE6DPqawStfjdKdT3uYrhzNsADuxLA+/METrPoQFUR2G26Y3oAdCRx/I0dQE4T6qmEefDN60Z0mpqHl44jcXk9mTTqqVwDbXJWH4UTF7b2m9j8iFDw0zGtXGCwvubJCzezxMls0/T8zmTDp0/X3/6CL42v457y3XwMfdCya5gq3a9/xdA8l01Kwg988Jp36RVayI8b5Su4vasrnmPtk4sHCfP/Q== jhs@jason-smiths-imac.local |
| // Example MX response with dnsd | |
| // | |
| // To test: | |
| // 1. Run this program | |
| // 2. dig @localhost -p 5353 example.com mx | |
| var dnsd = require('dnsd') | |
| var server = dnsd.createServer(handler) | |
| server.zone('example.com', 'ns1.example.com', 'us@example.com', 'now', '2h', '30m', '2w', '10m') |
| ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAuWgWS41PlgjH1usjBOo6NFUoz8/g1HVZC6yBNP43vP2Iyajn8JkSLnLNkq72ndFQ9idZXjbfaJvxMWK8m5kBuiQm6EEws09jq7H5xtMY94nbhb+BCSO3sluuHw9hYlsEIWDHaegou5Y+UoyH1s8jsDggR7Wgv6TUp2RXdJ2ZO4zmLu72EJpYVx45iELxGmdxm9DE1FBNjZ33/i2T/5EpNyiFwVwA8pPfKTT42R2Wkig1aybc+wMoktBrcJ7JPgdu7qI+x8cz9fwm1r+Af2e8bTv+tQebFRukoej2DW+6pwDnTNJHrEz0zNVUVyyVfXTjWciK5T4IQq1Bp256sQcO8w== jhs@air.local |
| -module(my_first_couchdb_plugin). | |
| -export([handler/1]). | |
| handler(Req) -> ok | |
| , Bugs = couch_config:get("first", "enable_bugs", "false") | |
| , {Code, Body} = case Bugs | |
| of "false" -> ok | |
| , {200, {[ {hello, <<"world">>} ]}} | |
| ; _ -> ok |
I (Jason) am very sorry but I will be offline for the next several hours and people still have busted conflicted npm packages. Here is a workaround.
The workaround is simply to touch your document over and over (i.e. GET and then PUT it back unchanged). You can use Futon https://isaacs.iriscouch.com/_utils/ and log in as your npm user, or use curl with basic auth, or write some JS even.
Once a doc revision has a longer change history, it becomes the winning revision and mostly shadows out all other revisions. That's good enough for npm. From there an npm publish —force usually puts things right I do not want to risk writing experimental code that is modifying and merging documents in an exhausted state. That's how things go from bad to worse.
| jhs@air:~$ curl isaacs.ic.ht/registry/_design/app > app.json | |
| jhs@air:~$ node -e 'app = JSON.parse(require("fs").readFileSync("app.json")); console.log(app.updates.package)' > package.js | |
| jhs@air:~$ grep -A 10 'if(newdoc._attachments)' package.js | |
| if(newdoc._attachments) { | |
| var inline = false | |
| for(var k in newdoc._attachments) { | |
| if(newdoc._attachments[k].data) { | |
| doc._attachments[k] = newdoc._attachments[k] | |
| inline = true | |
| } |