| // Hash Tables | |
| // The rate of collusion is determined by how good the hash function is | |
| // - A good hashing function is the key to an efficient hash table | |
| // Search - best case O(1), worst case O(n) (based on the frequency of collusions) | |
| // Handling collisions | |
| // - seperate chaning * | |
| // - open addressing |
| This is a way to measure the complexity of an algorithim (i.e the runtime). These measurement is usually done based on Space and Time. | |
| O(1) - Constant | | |
| O(n) - Linear | | |
| O(log n) - Logrithmic | Best to Worst | |
| O(n log n) - Linearithmic | | |
| O(n ^ 2) - Exponential | | |
| O(n!) - Factorial V | |
| Op |
| const puppeteer = require("puppeteer"); | |
| const css = require("css"); | |
| const chalk = require("chalk"); | |
| const fs = require("fs"); | |
| let browser = null; | |
| let links = null; | |
| /*const links = ['https://www.comparethemarket.com', | |
| 'https://www.comparethemarket.com/car-insurance/', | |
| 'https://www.comparethemarket.com/home-insurance/', |
Provides set of operations to efficiently maintain set of patch for long time and be able to submit those for review.
Let's say we clone a repo and 'master' is upstream branch and we will keep it up-to-date on regular base.
We can created a branch for a new feature and will try to keep it fresh and with addressed reviews.
The Firefox debugger has undergone a massive rewrite in the last two years, moving away from old Mozilla-specific technologies like XUL etc, to more modern technologies like React, webpack and babel.
[Babel][babel] is a tool for compiling Javascript into Javascript. It generates an [Abstract Syntax Tree (AST)][ast_wiki] which can be transformed, transversed or manipulated in various ways for use. Babel and AST's have played a major part in growth of the modern web tooling ecosystem.
Over the past year, we have used babel extensively in building the debugger, from disabling non-executable lines so breakpoints cannot be set to highlighting out of scope code and much more.
I felt it would be nice to write a couple of blog posts, documenting some of the use cases and looking into some debugger internals as we go.
| In the scenario below task2 depends on the result from task1 which is stored | |
| in value property of the meta object(this is just an example) which does not initially exist but is created from within | |
| task1. task2 can later have access to the value using <%= meta.value %> at a later time. | |
| This way two tasks can share data.. | |
| There may be better ways of doing this, if you have come across please share | |