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.
| # Hello, and welcome to makefile basics. | |
| # | |
| # You will learn why `make` is so great, and why, despite its "weird" syntax, | |
| # it is actually a highly expressive, efficient, and powerful way to build | |
| # programs. | |
| # | |
| # Once you're done here, go to | |
| # http://www.gnu.org/software/make/manual/make.html | |
| # to learn SOOOO much more. |
| 'use strict'; | |
| import {Router5, RouteNode} from 'router5'; | |
| import logger from '../logger'; | |
| // The set of valid sink functions includes synchronous state-affecting router functions that do not require a callback | |
| // and which do not have a significant return value other than the router object itself. | |
| const validSinkFuncs = ['add','addNode','canActivate','deregisterComponent','navigate','registerComponent','setOption','start','stop']; | |
| function validateAndRemapSinkArgument(arg) { |
| # requires: 256 color terminal | |
| /script install iset.pl | |
| /script install buffers.pl | |
| /script install colorize_nicks.py | |
| /set weechat.look.buffer_notify_default message | |
| /set weechat.look.color_nick_offline on | |
| /set weechat.look.prefix_action " •" | |
| /set weechat.look.prefix_join "▬▶" |
| (set-env! :dependencies '[ | |
| [org.clojure/clojure "1.8.0" :scope "provided"] | |
| [org.clojure/clojurescript "1.9.89" :scope "provided"] | |
| [ajchemist/boot-figwheel "0.5.4-5"] ;; latest release | |
| [org.clojure/tools.nrepl "0.2.12" :scope "test"] | |
| [com.cemerick/piggieback "0.2.1" :scope "test"] | |
| [figwheel-sidecar "0.5.4-5" :scope "test"] | |
| [pandeiro/boot-http "0.7.2" :scope "test"]]) |
| vec3 gammaCorrect(vec3 color, float gamma){ | |
| return pow(color, vec3(1.0/gamma)); | |
| } | |
| vec3 levelRange(vec3 color, float minInput, float maxInput){ | |
| return min(max(color - vec3(minInput), vec3(0.0)) / (vec3(maxInput) - vec3(minInput)), vec3(1.0)); | |
| } | |
| vec3 finalLevels(vec3 color, float minInput, float gamma, float maxInput){ | |
| return gammaCorrect(levelRange(color, minInput, maxInput), gamma); |
CertSimple just wrote a blog post arguing ES2017's async/await was the best thing to happen with JavaScript. I wholeheartedly agree.
In short, one of the (few?) good things about JavaScript used to be how well it handled asynchronous requests. This was mostly thanks to its Scheme-inherited implementation of functions and closures. That, though, was also one of its worst faults, because it led to the "callback hell", an seemingly unavoidable pattern that made highly asynchronous JS code almost unreadable. Many solutions attempted to solve that, but most failed. Promises almost did it, but failed too. Finally, async/await is here and, combined with Promises, it solves the problem for good. On this post, I'll explain why that is the case and trace a link between promises, async/await, the do-notation and monads.
First, let's illustrate the 3 styles by implementing
| home := $${HOME} | |
| shell := /bin/bash | |
| nix := /nix/var/nix | |
| nix_darwin := /run | |
| brew := /opt/homebrew | |
| key := id_ed25519 | |
| public_key := .ssh/$(key).pub | |
| github_key := .ssh/github.txt |
| # A Firefox Quantum ViewSourceWith replacement for Windows | |
| # | |
| # Usage: | |
| # (1) Save as C:\path\to\script.ps1 | |
| # (2) In order to run your own powershell scripts, start PowerShell | |
| # as Administrator and run the command | |
| # | |
| # Set-ExecutionPolicy RemoteSigned | |
| # | |
| # (2) You can test the proper running (from a user cmd): |
