I had to fork and patch a Node program last week as it was exhibiting some bad performance characteristics on Windows due to an unstable node FS feature (chokidar, for anyone interested, and it was down to fs.watch vs fs.watchFile whose performance and stability varies by platform).
As part of this, I realised that while I could hack the built code in my npm repo, I’d A) never forked code before and B) didn’t know how to test my changes i.e. get a package.json pointing at my forked code, and C) actually do a pull request.
Turns out it’s quite easy! The post on debuggable linked just above walks you through forking it, and the pull request process was fairly easy following the Github Using Pull Requests doc.
One thing I did differently was to not use the commit # in my package.json for testing, and instead used ”chokidar”: “https://github.com/alextreppass/chokidar/tarball/master”
The only thing I didn’t do properly, and the msysgit Windows UI hadn’t told me about, was setting my username and email so that Github would alias it to me on the pull request’s page. Command-line git moaned at me with a suggestion on how to fix it; here’s a page on how to set your username and email in the git config.
The recent revelations by the whistleblower Edward Snowden were fascinating. But they - and all the reactions to them - had one enormous assumption at their heart. That the spies know what they are doing. But when you look at the history of MI5 the astonishing thing is they never seem to know what…
Dividing up complex work, especially rendering work, is best done in chunks so as not to block the JS thread. This has been historically done using setTimeout(fn, 0), but browsers apparently peg that to a timer waiting at least 4ms.
setImmediate(fn) is a new feature in IE10+ which gets around this - no timer, and the callback happens as soon as the last UI task in the current event loop completes.
Mozilla and WebKit are apparently against adding it at the moment; we’ll see how long they hold out.
Interesting trade-off between offering options in your product that might appear to the average user to break things (“Firefox is broken again, this site won’t show!”), the increased cost of development for older browsers that don’t support modern web standards, and the usability, security and privacy considerations that come with allowing JS to run everywhere.
Particularly interesting are the recommendations for version APIs using URL parameters, and that pretty printing should be enabled by default. I guess in the modern age a small overhead of whitespace characters aren’t going to make much difference, especially when you’re gzipping the responses