diff --git a/gatsby-ssr.js b/gatsby-ssr.js
index 5c333c18ce..f4bdb3b6ed 100644
--- a/gatsby-ssr.js
+++ b/gatsby-ssr.js
@@ -24,7 +24,8 @@ exports.onRenderBody = function ({ setHeadComponents, setPostBodyComponents }) {
-
+
+
]);
diff --git a/src/pages/docs/javascript/cs-basics-in-js.md b/src/pages/docs/javascript/cs-basics-in-js.md
index bb2ab78087..b78d709049 100644
--- a/src/pages/docs/javascript/cs-basics-in-js.md
+++ b/src/pages/docs/javascript/cs-basics-in-js.md
@@ -3,18 +3,357 @@ title: CS Basics
weight: 0
excerpt: Computer Science Basics In JavaScript
seo:
- title: ''
- description: ''
- robots: []
- extra: []
+ title: ''
+ description: ''
+ robots: []
+ extra: []
template: docs
---
-Etiam facilisis lacus nec pretium lobortis. Praesent dapibus justo non efficitur efficitur. Nullam viverra justo arcu, eget egestas tortor pretium id. Sed imperdiet mattis eleifend. Vivamus suscipit et neque imperdiet venenatis.
-
-> Vestibulum ullamcorper risus auctor eleifend consequat.
-
+### Anonymous Closures
-In malesuada sed urna eget vehicula. Donec fermentum tortor sit amet nisl elementum fringilla. Pellentesque dapibus suscipit faucibus. Nullam malesuada sed urna quis rutrum. Donec facilisis lorem id maximus mattis. Vestibulum quis elit magna. Vestibulum accumsan blandit consequat. Phasellus quis posuere quam.
+This is the fundamental construct that makes it all possible, and really is the single **best feature of JavaScript**. We’ll simply create an anonymous function, and execute it immediately. All of the code that runs inside the function lives in a **closure**, which provides **privacy** and **state** throughout the lifetime of our application.
-Vivamus mollis in tellus ac ullamcorper. Vestibulum sit amet bibendum ipsum, vitae rutrum ex. Nullam cursus, urna et dapibus aliquam, urna leo euismod metus, eu luctus justo mi eget mauris. Proin felis leo, volutpat et purus in, lacinia luctus eros. Pellentesque lobortis massa scelerisque lorem ullamcorper, sit amet elementum nulla scelerisque. In volutpat efficitur nulla, aliquam ornare lectus ultricies ac. Mauris sagittis ornare dictum. Nulla vel felis ut purus fermentum pretium. Sed id lectus ac diam aliquet venenatis. Etiam ac auctor enim. Nunc velit mauris, viverra vel orci ut, egestas rhoncus diam. Morbi scelerisque nibh tellus, vel varius urna malesuada sed. Etiam ultricies sem consequat, posuere urna non, maximus ex. Mauris gravida diam sed augue condimentum pulvinar vel ac dui. Integer vel convallis justo.
\ No newline at end of file
+```js
+(function () {
+ // ... all vars and functions are in this scope only
+ // still maintains access to all globals
+})();
+```
+
+Notice the `()` around the anonymous function. This is required by the language, since statements that begin with the token `function` are always considered to be **function declarations**. Including `()` creates a **function expression** instead.
+
+### Global Import
+
+JavaScript has a feature known as **implied globals**. Whenever a name is used, the interpreter walks the scope chain backwards looking for a `var` statement for that name. If none is found, that variable is assumed to be global. If it’s used in an assignment, the global is created if it doesn’t already exist. This means that using or creating global variables in an anonymous closure is easy. Unfortunately, this leads to hard-to-manage code, as it’s not obvious (to humans) which variables are global in a given file.
+
+###### Luckily, our anonymous function provides an easy alternative. By passing globals as parameters to our anonymous function, we **import** them into our code, which is both **clearer** and **faster** than implied globals. Here’s an example:
+
+```
+(function ($, YAHOO) {
+// now have access to globals jQuery (as $) and YAHOO in this code
+}(jQuery, YAHOO));
+```
+
+### Module Export
+
+Sometimes you don’t just want to _use_ globals, but you want to _declare_ them. We can easily do this by exporting them, using the anonymous function’s **return value**. Doing so will complete the basic module pattern, so here’s a complete example:
+
+```js
+let MODULE = (function () {
+ let my = {},
+ privateVariable = 1;
+
+ function privateMethod() {
+ // ...
+ }
+
+ my.moduleProperty = 1;
+ my.moduleMethod = function () {
+ // ...
+ };
+
+ return my;
+})();
+```
+
+Notice that we’ve declared a global module named `MODULE`, with two public properties: a method named `MODULE.moduleMethod` and a variable named `MODULE.moduleProperty`. In addition, it maintains **private internal state** using the closure of the anonymous function. Also, we can easily import needed globals, using the pattern we learned above.
+
+###### ## Advanced Patterns
+
+While the above is enough for many uses, we can take this pattern farther and create some very powerful, extensible constructs. Lets work through them one-by-one, continuing with our module named `MODULE`.
+
+### Augmentation
+
+One limitation of the module pattern so far is that the entire module must be in one file. Anyone who has worked in a large code-base understands the value of splitting among multiple files. Luckily, we have a nice solution to **augment modules**. First, we import the module, then we add properties, then we export it. Here’s an example, augmenting our `MODULE` from above:
+
+```js
+let MODULE = (function (my) {
+ my.anotherMethod = function () {
+ // added method...
+ };
+
+ return my;
+})(MODULE);
+```
+
+We use the `var` keyword again for consistency, even though it’s not necessary. After this code has run, our module will have gained a new public method named `MODULE.anotherMethod`. This augmentation file will also maintain its own private internal state and imports.
+
+### Loose Augmentation
+
+While our example above requires our initial module creation to be first, and the augmentation to happen second, that isn’t always necessary. One of the best things a JavaScript application can do for performance is to load scripts asynchronously. We can create flexible multi-part modules that can load themselves in any order with **loose augmentation**. Each file should have the following structure:
+
+```
+let MODULE = (function (my) {
+// add capabilities...
+
+###### return my;
+}(MODULE || {}));
+```
+
+In this pattern, the `var` statement is always necessary. Note that the import will create the module if it does not already exist. This means you can use a tool like [LABjs](http://labjs.com/) and load all of your module files in parallel, without needing to block.
+
+### Tight Augmentation
+
+While loose augmentation is great, it does place some limitations on your module. Most importantly, you cannot override module properties safely. You also cannot use module properties from other files during initialization (but you can at run-time after intialization). **Tight augmentation** implies a set loading order, but allows **overrides**. Here is a simple example (augmenting our original `MODULE`):
+
+```js
+let MODULE = (function (my) {
+ let old_moduleMethod = my.moduleMethod;
+
+ my.moduleMethod = function () {
+ // method override, has access to old through old_moduleMethod...
+ };
+
+ return my;
+})(MODULE);
+```
+
+Here we’ve overridden `MODULE.moduleMethod`, but maintain a reference to the original method, if needed.
+
+### Cloning and Inheritance
+
+```js
+let MODULE_TWO = (function (old) {
+ let my = {},
+ key;
+
+ for (key in old) {
+ if (old.hasOwnProperty(key)) {
+ my[key] = old[key];
+ }
+ }
+
+ let super_moduleMethod = old.moduleMethod;
+ my.moduleMethod = function () {
+ // override method on the clone, access to super through super_moduleMethod
+ };
+
+ return my;
+})(MODULE);
+```
+
+This pattern is perhaps the **least flexible** option. It does allow some neat compositions, but that comes at the expense of flexibility. As I’ve written it, properties which are objects or functions will _not_ be duplicated, they will exist as one object with two references. Changing one will change the other. This could be fixed for objects with a recursive cloning process, but probably cannot be fixed for functions, except perhaps with `eval`. Nevertheless, I’ve included it for completeness.
+
+### Cross-File Private State
+
+One severe limitation of splitting a module across multiple files is that each file maintains its own private state, and does not get access to the private state of the other files. This can be fixed. Here is an example of a loosely augmented module that will **maintain private state** across all augmentations:
+
+```js
+let MODULE = (function (my) {
+ let _private = (my._private = my._private || {}),
+ _seal = (my._seal =
+ my._seal ||
+ function () {
+ delete my._private;
+ delete my._seal;
+ delete my._unseal;
+ }),
+ _unseal = (my._unseal =
+ my._unseal ||
+ function () {
+ my._private = _private;
+ my._seal = _seal;
+ my._unseal = _unseal;
+ });
+
+ // permanent access to _private, _seal, and _unseal
+
+ return my;
+})(MODULE || {});
+```
+
+Any file can set properties on their local variable `_private`, and it will be immediately available to the others. Once this module has loaded completely, the application should call `MODULE._seal()`, which will prevent external access to the internal `_private`. If this module were to be augmented again, further in the application’s lifetime, one of the internal methods, in any file, can call `_unseal()` before loading the new file, and call `_seal()` again after it has been executed. This pattern occurred to me today while I was at work, I have not seen this elsewhere. I think this is a very useful pattern, and would have been worth writing about all on its own.
+
+### Sub-modules
+
+Our final advanced pattern is actually the simplest. There are many good cases for creating sub-modules. It is just like creating regular modules:
+
+```js
+MODULE.sub = (function () {
+ let my = {};
+ // ...
+
+###### return my;
+})();
+```
+
+While this may have been obvious, I thought it worth including. Sub-modules have all the advanced capabilities of normal modules, including augmentation and private state.
+
+###### ## Conclusions
+
+Most of the advanced patterns can be combined with each other to create more useful patterns. If I had to advocate a route to take in designing a complex application, I’d combine **loose augmentation**, **private state**, and **sub-modules**.
+
+###### I haven’t touched on performance here at all, but I’d like to put in one quick note: The module pattern is **good for performance**. It minifies really well, which makes downloading the code faster. Using **loose augmentation** allows easy non-blocking parallel downloads, which also speeds up download speeds. Initialization time is probably a bit slower than other methods, but worth the trade-off. Run-time performance should suffer no penalties so long as globals are imported correctly, and will probably gain speed in sub-modules by shortening the reference chain with local variables.
+
+###### To close, here’s an example of a sub-module that loads itself dynamically to its parent (creating it if it does not exist). I’ve left out private state for brevity, but including it would be simple. This code pattern allows an entire complex heirarchical code-base to be loaded completely in parallel with itself, sub-modules and all.
+
+```js
+let UTIL = (function (parent, $) {
+ let my = (parent.ajax = parent.ajax || {});
+
+ my.get = function (url, params, callback) {
+ // ok, so I'm cheating a bit :)
+ return $.getJSON(url, params, callback);
+ };
+
+ // etc...
+
+###### return parent;
+})(UTIL || {}, jQuery);
+```
+
+
+# Summary:
+
+
+
+
+ recitation
+
+
+
+### Anonymous Closures
+
+```javascript
+(function () {
+ // ... all vars and functions are in this scope only
+ // still maintains access to all globals
+})();
+```
+
+### Global Import
+
+```javascript
+(function ($, YAHOO) {
+ // now have access to globals jQuery (as $) and YAHOO in this code
+})(jQuery, YAHOO);
+```
+
+### Module Export
+
+```javascript
+let MODULE = (function () {
+ let my = {},
+ privateVariable = 1;
+
+ function privateMethod() {
+ // ...
+ }
+
+ my.moduleProperty = 1;
+ my.moduleMethod = function () {
+ // ...
+ };
+
+ return my;
+})();
+```
+
+# Advanced Patterns
+
+### Augmentation
+
+```javascript
+let MODULE = (function (my) {
+ my.anotherMethod = function () {
+ // added method...
+ };
+
+ return my;
+})(MODULE);
+```
+
+### Loose Augmentation
+
+In this pattern, the let statement is always necessary. Note that the import will create the module if it does not already exist. This means you can use a tool like LABjs and load all of your module files in parallel, without needing to block.
+
+###### ```javascript
+
+let MODULE = (function (my) {
+// add capabilities...
+
+###### return my;
+
+})(MODULE || {});
+
+````
+
+### Tight Augmentation
+
+Here we’ve overridden MODULE.moduleMethod, but maintain a reference to the original method, if needed.
+
+###### ```javascript
+let MODULE = (function (my) {
+ let old_moduleMethod = my.moduleMethod;
+
+ my.moduleMethod = function () {
+ // method override, has access to old through old_moduleMethod...
+ };
+
+ return my;
+})(MODULE);
+````
+
+### Cloning and Inheritance
+
+```javascript
+let MODULE_TWO = (function (old) {
+ let my = {},
+ key;
+
+ for (key in old) {
+ if (old.hasOwnProperty(key)) {
+ my[key] = old[key];
+ }
+ }
+
+ let super_moduleMethod = old.moduleMethod;
+ my.moduleMethod = function () {
+ // override method on the clone, access to super through super_moduleMethod
+ };
+
+ return my;
+})(MODULE);
+```
+
+### Cross-File Private State
+
+```javascript
+let MODULE = (function (my) {
+ let _private = (my._private = my._private || {}),
+ _seal = (my._seal =
+ my._seal ||
+ function () {
+ delete my._private;
+ delete my._seal;
+ delete my._unseal;
+ }),
+ _unseal = (my._unseal =
+ my._unseal ||
+ function () {
+ my._private = _private;
+ my._seal = _seal;
+ my._unseal = _unseal;
+ });
+
+ // permanent access to _private, _seal, and _unseal
+
+ return my;
+})(MODULE || {});
+```
+
+### Sub-modules
+
+```javascript
+MODULE.sub = (function () {
+ let my = {};
+ // ...
+
+###### return my;
+})();
+```
+
+
+
+
\ No newline at end of file
diff --git a/src/pages/docs/tips/regex-tips.md b/src/pages/docs/tips/regex-tips.md
new file mode 100644
index 0000000000..3814e7a163
--- /dev/null
+++ b/src/pages/docs/tips/regex-tips.md
@@ -0,0 +1,152 @@
+---
+title: Regex Tricks
+weight: 0
+excerpt: Regex Tricks
+seo:
+ title: 'Regex Tricks'
+ description: 'Regular expressions make light work of single-character delimiters, which is why it’s so easy to remove markup from a string:'
+ robots: []
+ extra: []
+template: docs
+---
+
+
+Regular expressions make light work of **single-character delimiters**, which is why it’s so easy to remove markup from a string:
+
+```
+str = str.replace(/(<[\/]?[^>]+>)/g, '');
+```
+
+It’s the negation in the character class that does the real work:
+
+```
+[^>]
+```
+
+Which means _“anything except `<`“_. So the expression looks for the starting tag-delimiter and possible slash, then anything except the closing tag-delimiter, and then the delimiter itself. Easy.
+
+However comments are not so simple, because comment delimiters are comprised of **more than one character**. Multi-line comments in CSS and JavaScript, for example, start with `/*` and end with `*/`, but between those two delimiters there could be **any number of unrelated stars**.
+
+I often use multiple stars in comments, to indicate the severity of a bug I’ve just noticed, for example:
+
+```
+/*** this is a bug with 3-star severity ***/
+```
+
+But if we tried to parse that with a single negation character, it would fail:
+
+```
+str = str.replace(/(\/\*[^\*]+\*\/)/g, '');
+```
+
+Yet it’s not possible with regular expressions to say: _“anything except \[this sequence of characters\]”_, we can only say: _“anything except \[one of these single characters\]”_.
+
+So here’s the regular expression we need instead:
+
+```
+str = str.replace(/(\/\*([^*]|(\*+[^*\/]))*\*+\/)/gm, '');
+```
+
+The expression handles unrelated characters by **looking at what comes after them** — stars are allowed as long as they’re not followed by a slash, until we find one that is, and that’s the end of the comment.
+
+So it says: “`/` then `*` (then anything except `*` OR any number of `*` followed by anything except `/`)(and any number of instances of that) then any number of `*` then `/`“.
+
+(The syntax looks particular convoluted, because `*` and `/` are both special characters in regular expressions, so the ambiguous literal ones have to be escaped. Also note the `m` flag at the end of the expression, which means **multi-line**, and specifies that the regular expression should search across more than one line of text.)
+
+Using the same principle then, we can adapt the expression to search for any kind of complex delimiters. Here’s another one that matches HTML comments:
+
+```
+str = str.replace(/(]))*\-+>)/gm, '');
+```
+
+And here’s one for `CDATA` sections:
+
+```
+str = str.replace(/(<\!\[CDATA\[([^\]]|(\]+[^>]))*\]+>)/gm, '');
+```
+
+## 2\. Using Replacement Callbacks
+
+The `replace` function can also be **passed a callback** as its second parameter, and this is invaluable in cases where the replacement you want can’t be described in a simple expression. For example:
+
+```
+isocode = isocode.replace(/^([a-z]+)(\-[a-z]+)?$/i,
+ function(match, lang, country)
+ {
+ return lang.toLowerCase()
+ + (country ? country.toUpperCase() : '');
+ });
+```
+
+That example normalizes the capitalisation in language codes — so `"EN"` would become `"en"`, while `"en-us"` would become `"en-US"`.
+
+The first argument that’s passed to the callback is always the complete match, then each subsequent argument corresponds with the backreferences (i.e. `arguments[1]` is what a string replacement would refer to as `$1`, and so on).
+
+So taking `"en-us"` as the input, we’d get the three arguments:
+
+0. `"en-us"`
+1. `"en"`
+2. `"-us"`
+
+Then all the function has to do is enforce the appropriate cases, re-combine the parts and return them. Whatever the callback returns is what the replacement itself returns.
+
+But we don’t actually have to assign the return value (or return at all), and if we don’t, then the original string will be unaffected. This means we can use `replace` as a **general-purpose string processor** — to extract data from a string without changing it.
+
+Here’s another example, that combines the multi-line comment expression from the previous section, with a callback that extracts and saves the text of each comment:
+
+```
+let comments = [];
+str.replace(/(\/\*([^*]|(\*+[^*\/]))*\*+\/)/gm,
+ function(match)
+ {
+ comments.push(match);
+ });
+```
+
+Since nothing is returned, the original string remains unchanged. Although if we wanted to extract _and_ remove the comments, we could simply return and assign an empty-string:
+
+```
+let comments = [];
+str = str.replace(/(\/\*([^*]|(\*+[^*\/]))*\*+\/)/gm,
+ function(match)
+ {
+ comments.push(match);
+ return '';
+ });
+```
+
+## 3\. Working With Invisible Delimiters
+
+Extracting content is all very well when it uses standard delimiters, but what if you’re using **custom delimiters** that only your program knows about? The problem there is that **the string might already contain your delimiter**, literally character for character, and then what do you?
+
+Well, recently I came up with a very cute trick, that not only avoids this problem, it’s also as simple to use as the single-character class we saw at the start! The trick is to use **unicode characters that the document can’t contain**.
+
+Originally I tried this with _undefined_ characters, and that certainly worked, but it’s not safe to assume that any such character will always be undefined (or that the document won’t already contain it anyway). Then I discovered that Unicode actually reserves a set of code-points specifically for this kind of thing — so-called [noncharacters](http://en.wikipedia.org/wiki/Mapping_of_Unicode_characters#Noncharacters "Mapping of Unicode Characters (wikipedia.org)"), which will never be used to define actual characters. A valid Unicode document is not allowed to contain noncharacters, but a program can use them internally for its own purposes.
+
+I was working on CSS processor, and I needed to remove all the comments before parsing the selectors, so they wouldn’t confuse the selector-matching expressions. But they had to be replaced in the source with something that took up the same number of lines, so that the line-numbers would remain accurate. Then later they would have to be added back to the source, for final output.
+
+So first we use a regex callback to extract and save the comments. The callback returns a copy of the match in which all non-whitespace is converted to space, and which is delimited with a noncharacter either side:
+
+```
+let comments = [];
+csstext = csstext.replace(/(\/\*([^*]|(\*+([^*\/])))*\*+\/)/gm,
+ function(match)
+ {
+ comments.push(match);
+ return '\ufddf' + match.replace(/[\S]/gim, ' ') + '\ufddf';
+ });
+```
+
+That creates an array of comments in the same source-order as the spaces they leave behind, while the spaces themselves take-up as many lines as the original comment.
+
+Then the originals can be restored simply by replacing each delimited space with its corresponding saved comment — and since the delimiters are single characters, we only need a **simple character class** to match each pair:
+
+```
+csstext = csstext.replace(/(\ufddf[^\ufddf]+\ufddf)/gim,
+ function()
+ {
+ return comments.shift();
+ });
+```
+
+How easy is that!
diff --git a/src/pages/docs/tools/Archive.md b/src/pages/docs/tools/Archive.md
index 97ca251bb8..fd94cba314 100644
--- a/src/pages/docs/tools/Archive.md
+++ b/src/pages/docs/tools/Archive.md
@@ -11,7 +11,15 @@ seo:
template: docs
---
+# Archive
+
+
+
+ Archive
+
+
+
@@ -33,15 +41,12 @@ template: docs
frameborder="0" allow="accelerometer; autoplay; clipboard-write;
encrypted-media; gyroscope; picture-in-picture" allowfullscreen>
-
-
-
-
+
Resource Archive
@@ -63,7 +68,6 @@ template: docs
Google Drive
-
@@ -95,13 +99,10 @@ template: docs
-
-
-
-
+
Lambda Student Site
@@ -110,16 +111,13 @@ template: docs
-
-
-
-
+
@@ -134,31 +132,25 @@ template: docs
-
-
-
-
+
-
-
-
-
+
Interview
@@ -167,16 +159,13 @@ template: docs
-
-
-
-
+
@@ -189,8 +178,6 @@ template: docs
-
-
Speach Recognition api
@@ -209,9 +196,6 @@ template: docs
-
-
-
The Algos Bgoonz Branch
@@ -230,9 +214,6 @@ template: docs
-
-
-
@@ -263,13 +244,10 @@ template: docs
-
-
-
-
+
Text Tools
@@ -278,16 +256,13 @@ template: docs
-
-
-
-
+
@@ -301,16 +276,13 @@ template: docs
-
-
-
-
+
@@ -325,16 +297,13 @@ template: docs
-
-
-
-
+
@@ -349,16 +318,13 @@ template: docs
-
-
-
-
+
Border Builder
@@ -368,16 +334,13 @@ template: docs
-
-
-
-
+
diff --git a/src/pages/docs/tools/data-structures.md b/src/pages/docs/tools/data-structures.md
deleted file mode 100644
index eea24c3a05..0000000000
--- a/src/pages/docs/tools/data-structures.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: Data Structures
-weight: 0
-excerpt: Data Structures
-seo:
- title: ''
- description: ''
- robots: []
- extra: []
- type: stackbit_page_meta
-template: docs
----
-
-## Data Structures
diff --git a/stackbit-libris-theme@0.0.1 b/stackbit-libris-theme@0.0.1
deleted file mode 100644
index e69de29bb2..0000000000