| struct BST<K: Ord + Clone, V: Ord + Clone> { | |
| key: Option<K>, | |
| value: Option<V>, | |
| left: Option<Box<BST<K, V>>>, | |
| right: Option<Box<BST<K, V>>>, | |
| } | |
| impl<K: Ord + Clone, V: Ord + Clone> BST<K, V> { | |
| fn init() -> Box<BST<K, V>> { | |
| return Box::new(BST::<K, V> { |
Sources: aircrack-ng/rtl8812au, aircrack-ng/rtl8814au
Note: This guide is purposefully simple. If you would like more information about what exactly each command is doing, try:
man `the command in question`or go to the respective source repositories as mentioned above.
| default['sshd']['sshd_config']['AuthenticationMethods'] = 'publickey,keyboard-interactive:pam' | |
| default['sshd']['sshd_config']['ChallengeResponseAuthentication'] = 'yes' | |
| default['sshd']['sshd_config']['PasswordAuthentication'] = 'no' |
React recently introduced an experimental profiler API. After discussing this API with several teams at Facebook, one common piece of feedback was that the performance information would be more useful if it could be associated with the events that caused the application to render (e.g. button click, XHR response). Tracing these events (or "interactions") would enable more powerful tooling to be built around the timing information, capable of answering questions like "What caused this really slow commit?" or "How long does it typically take for this interaction to update the DOM?".
With version 16.4.3, React added experimental support for this tracing by way of a new NPM package, scheduler. However the public API for this package is not yet finalized and will likely change with upcoming minor releases, so it should be used with caution.
| /* | |
| Instructions for MacOS: | |
| - Install the fonts 'Operator Mono' & 'Fira Code' | |
| - Install theme 'Dark Candy' | |
| - Add the following config to the VS Code settings.json: | |
| { | |
| "editor.renderWhitespace": "all", | |
| "editor.fontSize": 14, |
| import React from "react"; | |
| import ReactDOM from "react-dom"; | |
| import configureStore from "./store/configureStore"; | |
| const store = configureStore(); | |
| const rootEl = document.getElementById("root"); |
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent
| # Copy and self modified from ys.zsh-theme, the one of default themes in master repository | |
| # Clean, simple, compatible and meaningful. | |
| # Tested on Linux, Unix and Windows under ANSI colors. | |
| # It is recommended to use with a dark background and the font Inconsolata. | |
| # Colors: black, red, green, yellow, *blue, magenta, cyan, and white. | |
| # http://xiaofan.at | |
| # 2 Jul 2015 - Xiaofan | |
| # Machine name. | |
| function box_name { |
While this gist has been shared and followed for years, I regret not giving more background. It was originally a gist for the engineering org I was in, not a "general suggestion" for any React app.
Typically I avoid folders altogether. Heck, I even avoid new files. If I can build an app with one 2000 line file I will. New files and folders are a pain.