alpha-one
Advanced tools
Readme
Table of Contents generated with DocToc
About: This is a meta-project to collect scattered thoughts about and working solutions for recurring tasks in Web- and Backend-Application building. Do not expect polished, working code, but rather fragmentary, sketchy hints.
The project takes its name from the 1970s British TV series Moonbase Alpha / Space: 1999.
Rationale: We often want to restrict access to the ressources a web application publishes; for example, you want subscribers to have unlimited access, guest users to enjoy a realistic peek into your offerings without handing over the full power of your application and the data therein, and at the same time deter any automated downloads. One part of the equation that can make this happen is User Authentication; the other is identifying anonymous visitors and selectively throttle or block their access, based on automatically collected behavior details and / or manual black- and whitelisting.
A limiter should be completely agnostic as to the task it is limiting—it should help to generally put limits to ressource usage, not, say, be built to specifically limit HTTP requests (a drop-in middleware could do that–one that uses a generic limiter).
Because of its genericity, a limiter should work with arbitrary ID tokens that represent clients—these could be any piece of data (an internal user ID, an IP address, a session ID) that is fit to identify a client in the sense of the application.
Since a limiter should be able to base its behavior on the past behavior of a given client and on the client's ranking (say, customer vs. guest vs. rogue), it must either entertain a suitable datastructure to keep such group affiliation and usage data (or else be fed (some of) these details when called).
Whether or not a limiter should take care of data persistence is an open question; ideally, server restart or redirection to another server process should not impact limiter behavior (this consideration would appear to favor Redis-like data persistence plans).
A limiter should distinguish between and be configurable for at least three behavioral patterns: full access, deferred (throttled) access, and denial of service (the last two with timeouts and permanent).
CoffeeNode Limit is an sttempt to bring all of the above points to the backend. It currently works with a slightly patched version of node-rate-limiter.
SCRATCH/alpha-one/src/ANSI256.coffee
https://github.com/Guilda/console-output-colorizer/blob/master/src/jquery.colorizeConsoleOutput.js
SCRATCH/includer/index.html
http://replit.github.io/jq-console/ (relies on an outdated version of jQuery; doesn't decode ANSI colors correctly; makes strange assumption about browser console element styling)
Using path-extra:
### https://github.com/jprichardson/node-path-extra ###
njs_path = require 'path-extra'
info njs_path.tempdir()
info njs_path.homedir()
info njs_path.datadir 'app-name-here'
See discussion of initialization vector (iv):
src/encryption.coffee
Probably use openpgpjs or sjcl:
The specific purpose of password encryption should probably be done using bcrypt, for which there are 100% JS implementations available. It does have the advantage of adaptable algorithmic complexity. APIs typically do not offer decryption, only comparison of data.
Our erstwhile solution to preparing CoffeeScript source files for both development and production, larq, is very much on the way out.
It still has one distinctive feature, though, and that is larq dev, which compiles a JavaScript file for
each CoffeeScript file that does not contain the actual code, but rather dynamically loads (and compiles)
the CoffeeScript source; in this way, the CoffeeScript sources may change any time, while to outside
consumers, everything appears as though code was actually loaded from JavaScript files, from the locations
where those JavaScript loader files are located.
Thus, every effort is made to make the existence of CoffeeScript sources transparent; the result is
convenience during development and assurance that production versions of the same code (produced with larq pub or coffee --compile) are fully functional (even in the absence of the CS sources—the plan is to
publish those, too, though, so potential contributors get a chance to work on either JS or CS, whatever they
feel most comfotable with).
I started larq ('Language-Aware ReQuire') when
I
realized that the global require.extensions
hook in NodeJS has huge problems—long story short, it's a global hook, so if any of your dependencies have
different ideas on how to resolve a particular filename extensions, you're BFE. It would be fine if it was
some very local thing, but as it stands, its not, and care must be exercised.
There are some thoughts on
how to repair this,
but so far no overarching facility or best-practices solution has emerged, short of the advisory to compile
your 3rd-party-language sources down to the standard ones (*.js, *.css, *.html) and only ever deal
with these compilation targets in production.
A possible, maybe makeshift solution is to use CoffeeNode Monitor or similar to watch all sources and compile on change; this may prove a better alternative than trying to do the same, but in more convoluted ways, using yet another tool (larq).
Rationale: When we want to have a single HTTP serving process to run on a production server, we can accomplish that by daemonizing the server process. Having more than one process and processes that are resumed after abortion requires more work. On a development machine, we want to typically have a single HTTP server to be run explicitly (not automatically on system startup), and, when any of its dependencies have been modified, we want to re-run any build steps and then restart the serving process. In case of syntax or runtime errors, we typically would like the monitoring instance to wait for any subsequent changes to the codebase and then try and re-run the build steps. A server is a Long Running Process—as distinguished from, say, a backup script that runs once a day for a minute or so. A Responsive Process is one that responds to (rather, is managed so it can respond to) changes in source files. A Persisting Process is one that is resumed on termination.
Generate TOC for your README.md with npm install --global doctoc:
OSX GitHub app
Rationale: With the advent of breaking changes in NodeJS unstable 0.11.x, many modules relying on gyp
/ waf do not compile any more. Some tools (such as browserify) compile with 0.11.7 but not with 0.11.8.
Consequently we must be able to switch between NodeJS versions in a swift and painless manner; n is one
way to do that:
Rationale. NodeJS makes it possible to use the same code on the server and in the browser; tools like
node-webkit make it possible to run one-file downloads as no-installation / 'portable' desktop apps (with
the VM (runtime) either bundled or installed globally on the target machine). This spells good-bye to all
(or at least most) of the many competing GUI toolkits (if and where a 70MB minimum size for the VM is
acceptable, where a given platform is supported, and where performance is sufficient).
Ordered from the earliest, most general, down to the latest, most specific steps, the 'stack of actions' in a web application may be sketched as follows:
Probably better than using float:
Rationale: getting away from <div class='foo'><div class='bar'>, moving towards <foo><bar>.
Probably need a polyfill for IE compatibility; without namespacing, custom tags may face problems with future updates to HTML5 standard.
FAQs
ideas about recurring tasks in Web- and Backend-Application building
The npm package alpha-one receives a total of 17 weekly downloads. As such, alpha-one popularity was classified as not popular.
We found that alpha-one demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
In an unprecedented surge, May 2024 saw the publication of over 5,000 CVEs, marking a historic milestone in cybersecurity with an average of 164 CVEs per day, nearly double the 2023 daily average.
Security News
The White House is addressing fragmented cybersecurity regulations as CISOs report spending up to 50% of their time on compliance, aiming to harmonize requirements and improve cybersecurity outcomes.
Security News
Research
The Socket Research Team has identified a malicious Python package that is typosquatting the popular crytic-compile utility, frequently used in popular toolkits and development environments for smart contracts and crypto applications.