| // ES6 version using asynchronous iterators, compatible with node v10.0+ | |
| const fs = require("fs"); | |
| const path = require("path"); | |
| async function* walk(dir) { | |
| for await (const d of await fs.promises.opendir(dir)) { | |
| const entry = path.join(dir, d.name); | |
| if (d.isDirectory()) yield* walk(entry); | |
| else if (d.isFile()) yield entry; |
| // Bug fixes for current versions. | |
| // | |
| // This server will start a bash shell and expose it | |
| // over socket.io to a browser. See ./term.html for the | |
| // client side. | |
| // | |
| // You should probably: | |
| // | |
| // npm install socket.io |
When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:
const Article = require('../../../../app/models/article');Those suck for maintenance and they're ugly.
| " copy all this into a vim buffer, save it, then... | |
| " source the file by typing :so % | |
| " Now the vim buffer acts like a specialized application for mastering vim | |
| " There are two queues, Study and Known. Depending how confident you feel | |
| " about the item you are currently learning, you can move it down several | |
| " positions, all the way to the end of the Study queue, or to the Known | |
| " queue. | |
| " type ,, (that's comma comma) |
This is by no means a comprehensive test. It was done a laptop with a dump of Google's homepage as the content. Performance data was generated using 10000 connections to localhost using `httperf'. If you see any glaring holes though, please point them out. Cheers!
| #!/bin/sh | |
| git clone [email protected]:cloudcmd/io-ru | |
| cd io-ru | |
| git submodule init | |
| git submodule update | |
| cd _layouts && git checkout master | |
| cd ../.. |
@ChiperSoft could you explain some of it in an email to me?
I suspect you may already have a general idea about it, since you've been arguing in favor of micro-services for some time. The basic idea is that you break your site down into lots of small applications.
Say you have a portal that is composed of multiple sections: front page, news, video, sports, discussion board, weather, video, etc. Each of those different sections would have their own backend content services driving them, independent APIs integrating with their own databases. You'd also have some form of centralized login & identity management service, some form of access control, and maybe a service for managing white-labeling if your portal is licensed by other companies.
Each of these sections on the site is a nodejs application by itself, responsible for handling only its own requests. This may be built using node's built in http server routines and a lot of in-house code, but most people are using some derivative of [Sencha Connect
This is a more wordy, narrative accompaniment to my pretty bare presentation about d3 that I gave to the jQuery DC Meetup.
Which is to say, d3 can be used for building things, but the 'atomic parts' are lower-level than bar graphs or projections or so on. This is a powerful fact. It also means that d3 is a good basis for simple interfaces, like Vega.js, that make its power accessible in other ways.
| #torrent | |
| sudo apt-get install deluged deluge-console deluge-web #password deluge | |
| #aria2c http://aria2.sourceforge.net/ | |
| #создать архив c прогрессбаром и записать его в файл | |
| tar -c cloud9 |gzip --stdout | pv > cloud9.tar.gz | |
| #ncurses problem debian | |
| sudo apt-get install libncurses5-dev libncursesw5-dev |
| --- | |
| layout: nil | |
| --- | |
| <?xml version="1.0" encoding="UTF-8"?> | |
| <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> | |
| {% for post in site.posts %} | |
| <url> | |
| <loc>http://tedhagos.com/misc/{{ post.url }}</loc> | |
| <lastmod>{{ post.date | date_to_xmlschema }}</lastmod> | |
| <changefreq>daily</changefreq> |
