{ | |
"scripts": { | |
"build": "npm run build:es2015 && npm run build:esm && npm run build:cjs && npm run build:umd && npm run build:umd:min", | |
"build:es2015": "tsc --module es2015 --target es2015 --outDir dist/es2015", | |
"build:esm": "tsc --module es2015 --target es5 --outDir dist/esm", | |
"build:cjs": "tsc --module commonjs --target es5 --outDir dist/cjs", | |
"build:umd": "rollup dist/esm/index.js --format umd --name YourLibrary --sourceMap --output dist/umd/yourlibrary.js", | |
"build:umd:min": "cd dist/umd && uglifyjs --compress --mangle --source-map --screw-ie8 --comments --o yourlibrary.min.js -- yourlibrary.js && gzip yourlibrary.min.js -c > yourlibrary.min.js.gz", | |
} | |
} |
https://gist.github.com/ljharb/58faf1cfcb4e6808f74aae4ef7944cff
While attempting to explain JavaScript's reduce
method on arrays, conceptually, I came up with the following - hopefully it's helpful; happy to tweak it if anyone has suggestions.
JavaScript Arrays have lots of built in methods on their prototype. Some of them mutate - ie, they change the underlying array in-place. Luckily, most of them do not - they instead return an entirely distinct array. Since arrays are conceptually a contiguous list of items, it helps code clarity and maintainability a lot to be able to operate on them in a "functional" way. (I'll also insist on referring to an array as a "list" - although in some languages, List
is a native data type, in JS and this post, I'm referring to the concept. Everywhere I use the word "list" you can assume I'm talking about a JS Array) This means, to perform a single operation on the list as a whole ("atomically"), and to return a new list - thus making it mu
var Middleware = function() {}; | |
Middleware.prototype.use = function(fn) { | |
var self = this; | |
this.go = (function(stack) { | |
return function(next) { | |
stack.call(self, function() { | |
fn.call(self, next.bind(self)); | |
}); |
Thanks to @seejee for making this for me!!!
The goal of this is to have an easily-scannable reference for the most common syntax idioms in C# and Rust so that programmers most comfortable with C# can quickly get through the syntax differences and feel like they could read and write basic Rust programs.
What do you think? Does this meet its goal? If not, why not?
# _______ __ __ _______ ______ _______ _______ _______ ______ # | |
#| || | | || || | | _ || || || | # | |
#| _ || | | ||_ _|| _ || |_| ||_ _|| ___|| _ |# | |
#| | | || |_| | | | | | | || | | | | |___ | | | |# | |
#| |_| || | | | | |_| || | | | | ___|| |_| |# | |
#| || | | | | || _ | | | | |___ | |# | |
#|_______||_______| |___| |______| |__| |__| |___| |_______||______| # | |
# # | |
# Modern CMake practices and importing the QT scripts by adding it to # | |
# your module path makes things a lot better than it used to be # |
Step 1: | |
Go to: C:\Windows\System32\Drivers\etc\hosts | |
And add this to the bottom of the file: | |
============= | |
127.0.0.1 your.domain.com | |
============= | |
Step 2: | |
Go to [your XAMPP directory]/apache/conf/httpd-xampp.conf |
import javafx.application.Application; | |
import javafx.beans.value.*; | |
import javafx.collections.*; | |
import javafx.scene.Scene; | |
import javafx.scene.control.*; | |
import javafx.scene.layout.VBox; | |
import javafx.stage.Stage; | |
public class ChoiceBoxBackedByDatabaseIds extends Application { | |
public static void main(String[] args) throws Exception { launch(args); } |