RoadMap
## To focus on works at hand, I need to look ahead and be assured
- open source project participation as real world working experience
- participation is to demonstrate you are good at reading harder codebase, fixing bugs, adding new features and communicate them
- watch and code curriculum teaches us the first three and support us with the fourth one by question-asking and feedback loops.
- Also to restore the actual participation experience to students, advanced students who participated in the open source projects are sharing their experience in meeting videos, e.g., Syntax Highlighting by Janelle de Ment [video](https://watchandcode.com/courses/77710/lectures/11078838)
- watch and code is preparing us for real open source project participation. In the process students learn towards this goal in simulation projects from simple to complex. Of course, some may say the actual participation of real project is still different (real people, real problem, real communication back and forth). However, we should not mythify it, after all it just consists of reading source, fixing bug, writing new features, communicate them, which we have and will kept doing in the curriculum.
- in other words, real open source project could just be watch and code final simulation projects. Why still simulation? because 1) we can't simulate the actual real world experience logically or in theory; 2) but the solved issues, bugs and communication process have saved openly by mozilla; 3) so, in theory we got all the resources to recreate the bug, and simulate the communication environment, to allow students gain the experience Jaril and Janelle had in exploring the just right issues they have encountered; 4) this way, we don't need to rely on luck to find the appropriate level of bugs or issues in the real project to learn; on the contrary, we should be able to find enough issues/bugs on all levels in real project and turn them into open source project participation simulation throughout different sections of our watch and code curriculum.
- my **question**:
- bad question: "how long does it take me to become a job ready as a professional software dev?"
- I know it is bad question as it is difficult to answer on individuals, but I can't help to ask about it in my mind often.
- good question: "how feasible is it to turn advanced students participation in real world open source projects into open source project participation simulation throughout watch and code curriculum?" ❓
## How to get the most out of advanced students open source project experience sharing? ❓
I can't get the firefox debugger properly started running at the moment, therefore I can't properly experiment with the software. But it should not stop us from learning from the experience advanced students have in open source project. I think students who were watching videos can benefit a lot if a little more information below is provided. :zap:
- [ ] where is the bug issue reported? (showed and read, but the link is missing)
- [x] what did you do with the issue? (e.g., Janelle reproduced the bug with your machine and example, demonstrated in the video)
- [ ] Where is the back and forth communication between you and the container? (links?)
- [ ] Where is the code responsible for the bug and where is the changed code to correct it? (links?)
- [ ] Is there anything in the communication or else in the process you wish you could have done better or avoid doing?
Debugger
- debugger is your most intimate guide
- you can actually write code and run debugger in chrome console altogether
- but I think I will use vscode+chrome most of the time
Questioner
- be good at asking question is a great deal
- How-to Ask Good Questions [goto](https://medium.com/@gordon_zhu/how-to-be-great-at-asking-questions-e37be04d0603)
- Ask with a template [goto](https://github.com/gordonmzhu/questions/issues/new?template=Custom.md)
Live Coding
## Recording my own daily live coding
- Reading without Coding is doing Nothing! :zap:
- enforce coding with patience
- enforce examine thought and coding process
- enforce good writing
- enforce rewatch, reflect, improvement next time
- [playlist](https://youtu.be/wQ4n5SsVU0U?list=PLx08F1efFq_X6rFsVycEYOoH6BSuNCDgm)
Testing
## Test and Rewrite Procedures
1. read docs and specs ⭐️ extremely slowly and carefully
- to get out as many use cases as possible
2. each use case (or test) should be as tiny, explicit, ation-specific as possible
- each use case focuses on a single, specific utility or action (not two or more combined)
- improve on the description iteratively
- reorganize the order of tests from simple to complex
3. write your test as tiny, simple, easy as possible
- only write codes to test what you set out to test in the description above
- start with the simplest array, e.g., [0] or [1,2]
4. make sure the official method and polyfill code pass all of your tests
- meanwhile, you may think of some edge use cases or tests
5. rewrite your function from scratch by building it up one test by another
- your function should pass all tests of course
6. refactor your code
- to link source codes with particular tests
- to refactor with util functions
- to organize using section comments
7. read pseudo-source code and polyfill code
- find out what your code is missing
- how you could refactor your code better
I found this sequence of working is very helpful, when I was doing it, I felt confident that I won't miss anything important, and can easily focused on coding the very specific problem at hand. Because when I did miss some important use case or test, it will be caught in step 5 onward.
## How to learn from good code?
1. exhaust all use cases
- code authors are humans, we think of ends (use cases) first and then means to achieve it
- reading use cases out of docs, specs
- step into the shoes of the author and freely experimenting other possible edge use cases
- read pseudo-source and polyfill to discover hidden use cases
2. reorganize use cases from simple to complex
3. case by case, gradually writing up your code
4. refactor your code
5. compare your code with polyfill and source to discover the good or better way of doing it
6. learn the new tricks from the good code from specific context of use cases
## Apply testing approach to smallTest.js library
1. smallTest.js is a very small library, but you can't write it by memorizing it
2. the best way to write it your own is first to write up docs or specs
3. then break the docs and specs into features and tests
4. write up the library step by step through tests from simple to complex
Coding Independently
- avoid the pleasure of discovering being taken away
- but watch ahead to get an idea what is taught and not
Clear All My Doubts
- Watch and Code philosophy in coding ability evolution [video](https://watchandcode.com/courses/77710/lectures/3597241)
- Why mainstream full stack curriculum makes you useless [video](https://watchandcode.com/courses/77710/lectures/3597245)
- WatchAndCode Road Map Rocks! [video](https://watchandcode.com/courses/77710/lectures/3597248)
- The more difficult coding practice advanced students do [the book](https://watchandcode.com/courses/77710/lectures/8466137)
- Open source contribution lead to job and meaning [video](https://watchandcode.com/courses/77710/lectures/8648254)
- how to find a project that suits you [video](https://watchandcode.com/courses/77710/lectures/8655069)
- better ways of searching for open source projects [video](https://watchandcode.com/courses/77710/lectures/9135675)
- Success of student story Anthony [video](https://watchandcode.com/courses/77710/lectures/11120379)
potential rabbit holes
- Wrong: spend too much time on getting started with Open Source and get frustrated about it
- Right: focus on curriculum (later the library, the book will be extremely helpful in help tackle hard codes), because the core of doing open source is still reading harder source codes and experiment and improve on them
- Wrong: try to read the **entirety** of MDN docs or ES specs
- Right: Watch and Code Curriculum + howto ES specs + (Docs HTML or Node when necessary)
rabbit holes for sure
- Wrong: Another "great" JS book
- Wrong: assume your problems demand complex solutions you never learn before
- right: try the most obvious solutions or possibilities first
- e.g., maze-stealer go live locally went wrong due to href and src links are written incorrectly, rather than needing npm commands
- Wrong: recall memories of the past mistakes and stupidities
- right: focus on what is at hands right now
- wrong: diving into some library or function source
- right: focusing on input-output
- wrong: diving into new fancy new tools, e.g., vscode Plugins
- right: focusing on the very few tools, e.g., chrome debugger, bookmarks
- wrong: diving into fastai, p5.js, d3.js now
- right: focus on the most important, persist to the end!
why use cases
- enable us to write up function test by test from simple to complex (step by step)
how to create tests or use cases
- start from docs, specs, and even source code
- experimenting the function
Array methods
forEach
## The right order of doing use cases+rewrite
1. do all use cases **uc**
2. make sense from source code **ps**
3. rewrite the function to match with all use cases **re**
## Use Cases and Rewrites
- numCallbackRuns: [use case, thereafter uc](https://youtu.be/wQ4n5SsVU0U?list=PLx08F1efFq_X6rFsVycEYOoH6BSuNCDgm), [rewrite, thereafter re](https://youtu.be/xelrVkGcN50)
- currentValue: [uc](https://youtu.be/Uu1SW1t4tTI), [re](https://youtu.be/bXidg4DAcTA)
- indexCurrent: [uc](https://youtu.be/Tc92D8oSChQ), [re](https://youtu.be/WHAQH4C5X_U)
- arrayThirdArg: [uc](https://youtu.be/yhSElHSezR4), [re](https://youtu.be/7pBhLj86XBk)
- arrayShareReference [uc](https://youtu.be/yhSElHSezR4?t=186), [re](https://youtu.be/zQjRKdYDohQ)
- numCallbackRuns+currentValue [uc](https://youtu.be/qiBJukHovuI), [re](https://youtu.be/0vOIxIau08A)
- thisArg [uc](https://youtu.be/N7SxoFXTin0), [re](https://youtu.be/-KmJ9Iv-Jd0)
- returnUndefined [uc](https://youtu.be/Pj8aJnTeo4Q), [re](https://youtu.be/g6KUHo4bPSg)
- sparseArrayFiltered [uc](https://youtu.be/Pj8aJnTeo4Q), [re](https://youtu.be/t9lThZi6GOc)
- IterationFixedEvenArrayPushMore [uc](https://youtu.be/aCp-RyQ4gek), [re](https://youtu.be/1ctSQPoN-0E), [src](https://github.com/EmbraceLife/useCasesJS/blob/master/forEachRewrite/forEachMy.html#L138)
- onlyCurrentValueSetBeforeArrayMutate [uc](https://youtu.be/dHrhM1YEmnc), [re](https://youtu.be/6pFa02GzyNk)
- runsReducedIfArrayShift [uc](https://youtu.be/i7mYXYnp22M), [re](https://youtu.be/gMJxh1kL-ug)
## use cases and pseudo source code
- pseudo source in specs [uc](https://youtu.be/qIZJIq87Ams), [src](https://tc39.es/ecma262/#sec-array.prototype.foreach)
- makeSenseUseCasesWithSource [ps](https://youtu.be/41jZ9qjHU0Q)
## Side point learnt
- indexLeak: [explained](https://github.com/EmbraceLife/useCasesJS/issues/1#issuecomment-517581858), and [resolved](https://youtu.be/IREe2QF-kc0) by global scope for all for-loop index
filter
## The right order of doing use cases+rewrite
1. do all use cases **uc**
2. make sense from source code **ps**
3. rewrite the function to match with all use cases **re**
4. compare my version with polyfill version **src**
## use cases and rewrite
- filterElementsByCallback [uc](https://youtu.be/f4jogUFbLDs), [re](https://youtu.be/LFE8RfwXPTo), [improve test](https://youtu.be/ynEVKccOsd0)
- callbackAsTest [notice](https://youtu.be/c1O12h3N1o0) 📓
- threeArgsCallback [uc](https://youtu.be/rkzoaiyWOP0), [re](https://youtu.be/_LWJTydujCg), [improved](https://youtu.be/o4hmQhysI1A)
- thisArg [uc](https://youtu.be/l66fPZLiCIQ), [re](https://youtu.be/C9kOhNuG7_M), [improved](https://youtu.be/opKFI8CJu_U)
- sparseArrayMissingFiltered [uc](https://youtu.be/-XOF06h6hL8), [re](https://youtu.be/VNpJ275H6c8), [improved](https://youtu.be/PMTDQ0Ptd7E)
- sparseArrayFilterOutMissingKeepingUndefinedAndNull [uc](https://youtu.be/RYC3rPpx-SU) using `hasOwnProperty` instead of `hasProperty` in the specs is the only working solution I found.
- arrayMutableIterationsFixedAddedElementNoInvoke [uc](https://youtu.be/zy_CphiuOXg), [re](https://youtu.be/FWA8yIV2Y9Q), [improved](https://youtu.be/zKneHZEEl2A)
- the [MDN polyfill](https://github.com/EmbraceLife/useCasesJS/blob/master/filterRewrite/Array.prototype.filterPF.html) of `Array.prototype.filter`failed in this test because it missed a line of code at the step of 8.c.i in [specs](https://tc39.es/ecma262/#sec-array.prototype.filter)
- in my version of filter, [line 22](https://github.com/EmbraceLife/useCasesJS/blob/master/filterRewrite/filterMy.html#L22) does the trick.
- pushedElementsNotInvokeCallback [uc](https://youtu.be/oJPqGjJaevw), [re](https://youtu.be/jCPkO85rhLQ), [improved](https://youtu.be/x9iitHzOea4)
- iterationsFixedExistingValuesMutable [uc](https://youtu.be/wXQOUMnupWU), [re](https://youtu.be/34eM1mhVCZ0), [improved](https://youtu.be/PE6IG05pJg0)
- unshiftedElementsNotInvokeCallback [uc](https://youtu.be/k_wAYjWmQoU), [re](https://youtu.be/Jh_uw3I6Mao), [improved](https://youtu.be/0KDGAtzHuVQ)
- callback without return or return with `false` will return empty array
- pushedElementsWillInvokeCallbackIfShifted [uc](https://youtu.be/7A2bKUFTdFc), [re](https://youtu.be/v2jHcjtcNnQ), [improved](https://youtu.be/yneVDIg8l2E)
- there is always a way to do the `eq` test, e.g., using a if-elseif block [uc](https://youtu.be/lb63DZT4HYQ)
- polyfill [ps](https://youtu.be/SPKDeucoDOs)
- polyfill vs myVersion
- [src 1](https://youtu.be/MNnf-cL70Iw),
- `idx in array` is equivalent to `array.hasOwnProperty(idx)` to check about missing value
- [src 2](https://youtu.be/kaojAPk1C6s)
- polyfill version misses a line to match with the official version, `var currentEl = array[i];`
- to be exactly, polyfill version missed the step of 8.c.i in [specs](https://tc39.es/ecma262/#sec-array.prototype.filter)
- reading specs [part1](https://youtu.be/Y34xtRrami8), [part2](https://youtu.be/8qGohyS_NgM), [part3](https://youtu.be/mNl7GF0ahSI)
## Side benefits
- how to differentiate `i++` and `++i` [uc](https://youtu.be/HYckGiZcafQ)
- chrome debugger hover `++i` or `i++` will actually execute it and `i` will mutate [demo](https://youtu.be/SPKDeucoDOs?t=309)
## Notice
- Like forEach, in filter, the line `kValue = O[k]` is a must to ensure the newArray get the same value even when callback mutates the array
- `map` below does not have to have such a line.
map
- reading features from specs [video](https://youtu.be/NIeljbJBDhs)
- solidify features/tests from summary above [video](https://youtu.be/aWDVXVPOXQI)
- test 1: 3Args [uc video](https://youtu.be/IMlQpl9Uu_A)
- test 2: returnNewArrayWithCallbackResult [uc video](https://youtu.be/couK4_XydmQ)
- test 3: thisArg, object if provided, otherwise window (undefined in theory) [uc video](https://youtu.be/Hm0mImCsVws)
- test 4: numIterationsFixed, the number of elements of array before the first call to callback is recorded [uc video](https://youtu.be/aNakYN4icFg)
- test 5: AppendedElementNotInvokeCallback, [uc video](https://youtu.be/VvgchRmqILo)
- test 6: existingChangedItemInvokeCallback [uc video](https://youtu.be/yWik8WWG4xI)
- test 7: existingElementDeletedNotInvoke [uc video](https://youtu.be/K3PUCppFmfc)
- Polyfill works on all tests [uc video](https://youtu.be/udumZ1n4mKw)
- rewrite1: satistify 3Args [re video](https://youtu.be/-gaN93XZ1p8)
- rewrite2: return new array [re video](https://youtu.be/PFBJJ5ipjEs)
- rewrite3: thisArg [re video](https://youtu.be/onHJLIzoqhE)
- rewrite4: originalArrayLengthFixed [re video](https://youtu.be/HCy8mLFzvHo)
- rewrite5: pushedItemNotInvoke [re video](https://youtu.be/t7RaHOylQPI)
- rewrite6: existingChangedItemInvoke [re video](https://youtu.be/5nBAYJj95ys)
- rewrite7: existingElementDeletedNotInvoke [re video](https://youtu.be/bH3fjA3ABBA)
- read source [video](https://youtu.be/3wPSSnmnJEY)
- read Polyfill [video](https://youtu.be/ksYAEAuVitE), see what I learnt from it below
## a lot learnt from Polyfill based on specs
- Object(this)
- var len = O.length >>> 0; ::: equal to pseudo-code ToUnit32(O.length)
- typeof callback !== 'function' ::: check whether callback is a function or not
- throw new TypeError(callback + ' is not a function'); ::: how to throw an error
- arguments.length > 1 ::: arguments contains all args
- A = new Array(len); ::: create a new empty array with length `len`
- if (k in O) {} ::: equal to O.hasOwnProperty(k) being true or not
- mappedValue = callback.call(T, kValue, k, O); ::: call === bind + run
- A[k] = mappedValue; ::: to see the source code behind it is illuminating
reduce
- reading specs [part 1 video](https://youtu.be/AfuK5x_NbFk) and [part 2 video](https://youtu.be/M1kc6REhtGU)
- from summary of specs to features for testing [video](https://youtu.be/ZcFFmgNDhcU)
- Feature 0 ::: singleOutput ::: case 0: if no return in callback, reduce return undefined ::: case 1: if callback just return true, reduce return true ::: case 2: if normal, return a single value [video](https://youtu.be/nB4XP4f6SDE)
- Feature 1 ::: 4Args ::: callback can access four items from reduce ::: without optional initialValue, previousValue is the first value and currentValue is the second value. [video](https://youtu.be/Afgiw3C-ebo)
- Feature 2 ::: optionalArg ::: if initialValue provided, the previousValue will be the initialValue and currentValue be the first element value [video](https://youtu.be/MiL1SvCon1A)
- Feature 3 ::: TypeError ::: an empty array without optional arg (initialValue) will trigger an type error [video](https://youtu.be/OTZrY28RCqI)
- Feature 4 ::: totalIterations ::: if the new elements get added, but the total iterations stay the same [video](https://youtu.be/US18Ui-UDZc)
- Feature 5 ::: case 1: appended item won't invoke callback ::: case 2: but if the first element get deleted, the appended items can get to invoke callback [video](https://youtu.be/WHQw4sk2Dtg)
- Feature 6 ::: if next element's value changed now, in the next iteration the changed value will be passed to callback [video](https://youtu.be/LuZav58aeeQ)
- Feature 7 ::: elements deleted by callback before being passed to callback will not be visited by callback [video](https://youtu.be/Dexg25xIwSs)
- all 7 tests run OK with polyfill [video](https://youtu.be/aJkFc0_ZcFI)
- writeUp Reduce on feature 0 [video](https://youtu.be/LYY-QuqDbs0):
- I am not building this function from the simplest test, as I know the function well enough to start from the middle. Is this a good reason not to write the function from the most basic form?
- writeUp Reduce on feature 1 [video](https://youtu.be/1hGPpkAuQ8Q) : the previous writeup can cover this feature 1
- writeUp Reduce on feature 2 [video](https://youtu.be/bIV3zTHjVGo)
- writeUp Reduce on feature 3 [video](https://youtu.be/q-uF6xA-SxY)
- writeUp Reduce on feature 4 [video](https://youtu.be/sdfCqrachuk)
- writeUp Reduce on feature 5 [video](https://youtu.be/eKy1DcEX60A)
- writeUp Reduce on feature 6 [video](https://youtu.be/2A3sVEkvTik)
- writeUp Reduce on feature 7 [video](https://youtu.be/d9Z8NK6fpY8)
- source the pseudo source code [part1](https://youtu.be/oP5aWhSfCss), [part2](https://youtu.be/WjJSB0EuwPA)
- I don't get part of the code, so I think it is unnecessarily complex (see part2)
- Now, I get it, the seemingly unnecessary code handles front missing elements, this is a new test case (Hidden Feature [video](https://youtu.be/CGsK2wMXjQU))
- Another hidden feature which shows the middle missing values are handled with the use of `in`. Hidden Feature 2 [video](https://youtu.be/YbTxsHDUbk8)
- All features are ordered by complexity
- add smallTest.js to reduce and introduced `groupCollapse` to feature 1, 2, 12 [video](https://youtu.be/WJFVkQezV-c)
- apply `groupCollapse` to group all logs for all features of `reduce` [video1](https://youtu.be/sZqDjTiuJOY), [video2](https://youtu.be/NVoqVqAuuhE)
Why Open Source Project from Day1
# Why Open Source Project from Day1
(for premium course students of course)
- learning all about JS is the means, creating and contributing to useful, meaning software is the end;
- the end/goal (not the means) is the drive that keeps us learning and sharpening our skills in JS, that enables us to persist and stick to the end;
- I find potential voices of "you should wait till you are advanced students to start open source project" unnatural and unhealthy
- But it is important to note that getting started with firefox debugger project is tedious for now, and the library and the book content on curriculum are hard enough and should be great help to enable us reading difficult codebase in the debugger project. So, stay focused on the curriculum!
- parts of the content inside Open Source Project for Day 1 students should be and could be super easy
Open Source Project Progression
# Open Source Project Progression
How much is the gap from rewriting the library with the book to doing the same with the firefox debugger? ❓❓
- The book and the library is a huge step toward real life complex open source project
- between the library and the debugger, there seems to have ReactJS, ReduxJS to fill the gap
- What is the real understanding of the gap here?
How to get started with firefox debugger project?
# How to get started with firefox debugger project?
There are enormous amount of info on firefox debugger [page](http://firefox-dev.tools/debugger/). I found it's overwhelming to going through them, beside I want to focus on the curriculum without doing unnecessary research. So, I believe a series of lessons on how to get started is crucially important.
I have a few lesson suggestions on how to get started with firefox debugger project.
- how to get started to read Jaril Valenciano issues from start? ❓
- I realized searching within Bugzilla is not as easy as it sounds at all
- with google I found [user profile of Jaril](https://bugzilla.mozilla.org/user_profile?user_id=631100) but can't get a list of his contributions in order
- could this be the first lesson for the next weekly meeting?
- where and how to subscribe to receive all the necessary info on issues and bugs?
- how to set up so that I can start reading source and reproducing the bugs reported?
How to create a shortcut of a method for quick access?
## How to create a shortcut of a method for quick access?
- give the method a informative but much shorter name and bind with the object [video](https://youtu.be/BFKppNAU5Is), [source](https://github.com/EmbraceLife/useCasesJS/blob/master/tinytest.js)
How to create `eq` the equalization test function?
## How to create `eq` the equalization test function?
- [video](https://youtu.be/AxTWtCe21Tk)
- check whether two values are equal or not
- throw an error
- add informative message including variables
More examples on the use of bind in the library
- given `var eq = ...bind(TinyTest)`, `bind.this` inside `TinyTest.run` becomes unnecessary
- without `var eq = ...bind(...`, we need to use `this.assertEquals` inside our designed test examples instead of `eq`
- see [video](https://youtu.be/mIlR1hSgaAk)
setTimeOut, event loop
- what the heck is the event loop [video](https://youtu.be/8aGhZQkoFbQ), very clearly explained
ternary operator and constructor function
- [video time before 11:23](https://watchandcode.com/courses/77710/lectures/1600693)
- ternary operator is a shortcut to if condition block: `document.body.style.backgroundColor = (failures == 0 ? '#99ff99' : '#ff9999');`
- constructor vs normal function
```Javascript
function Person(age, name){
// this = {}; added if john = new Person(1, "J")
this.age = age; //if john = Person(1, "J"), this refers to window
this.name = name; //if john = Person(1, "J"), age and name are variables added to global context
// return this; added if john = new Person(1, "J")
}
```
Improve tinyTest.js as a product
- [source](https://github.com/EmbraceLife/useCasesJS/tree/master/smallTest)
```javascript
console.log("%cWe can color it up", "color: red");
console.groupCollapsed("make a drop list of logs");
console.log("Let's make an error log next");
console.error(e);
console.groupEnd();
```
- sometimes Google Web Api is better than MDN
- checkout `renderUpdate`
- [x] watch the last bit of video first, the purpose of this video is super helpful!
- [x] recreate what Gordon did on your own, just like I did with testing section, only for improve library this time
- [ ] improve the library as if it is your software product,
- how to keep working on code quality (a list of things to check)
- but more important how to keep working on product quality :zap:
- [x] codes+debugger rather than notes or videos should be your review
Write smallTest.js from Scratch
- write up docs to describe what does such a library do [video](https://youtu.be/b1QWRgFh2uw)
- turn docs description into code designs specs [video 1](https://youtu.be/qD3BWQDTzZ4), [video 2](https://youtu.be/UDYJ7r9GpWk)
read docs as a pro
- read docs (code examples) as codes, as codes won't lie, and codes are straightforward
- play with demos hard, test the limits, break them as much as you can, as this is the way to gain true understanding and even rewrite it
- docs is important because authors write the library with the use cases of docs in mind
- dive into the app using the library and see how it is made
- what is the stackoverflow link talking about writing code snippets that Gordon is talking about? ❓
- is it possible to provide resources links under each video lesson page?
- download repo, running and experimenting the docs locally, replace minified lib with normal lib, remove google+ codes at the bottom as it generates annoying warning messages
Docs Reading and Experimenting
- started reading the docs and experimented on `accounting.formatMoney` [video](https://youtu.be/TsysLi-2ZPA)
IIFE
```javascript
var number = 20;
(function(){
console.log(number); // 20
}())
(function(){
var number = 12;
console.log(number); // 12
}())
(function(root, undefined){
var number = 10;
console.log(number); // 10
}(this)) // var root = this = window; var undefined = undefined;
```
Watch and Code Digest