├── .github
    └── workflows
    │   └── action.yml
├── .mergify.yml
├── Android
    └── application fundamentals.md
├── Browser
    ├── BrowserXY.md
    ├── Cookie.md
    ├── Cookie_Store.md
    ├── FOUC.md
    ├── HTTP2_Websocket.md
    ├── IndexedDB_WebSQL.md
    ├── Layer_Model.md
    ├── WebWorker.md
    ├── Worklet.md
    ├── 웹 브라우저의 작동 원리.md
    └── 최신_브라우저의_내부_살펴보기.md
├── CS
    ├── Binding.md
    ├── Bomb-Lab(1).md
    ├── Call-By-Sharing.md
    ├── Counting-sort.md
    ├── Graph.md
    ├── Memory.md
    ├── Radix-sort.md
    ├── aspect-oriented-programming.md
    ├── cohension&coupling.md
    ├── compression.md
    ├── dependency-inversion-principle.md
    ├── grasp.md
    ├── information_theory.md
    ├── integer_representation.md
    ├── interface-segregation-principle.md
    ├── liskov_substitution_principle.md
    ├── methods_in_IPC.md
    ├── non-blocking.md
    ├── non-linear-search.md
    ├── open-closed-principle.md
    ├── soc.md
    ├── srp.md
    ├── union-find.md
    ├── 페이징과 세그먼테이션.md
    └── 플로이드-와샬-알고리즘.md
├── CSS
    ├── CJK.md
    ├── WebToMobile.md
    └── safe-area.md
├── Database
    ├── DB Connection Pool.md
    ├── Query Builder ( Knex.js).md
    └── Types of Databases.md
├── Deprecated
    ├── AMD와 CommonJS.md
    ├── Async-Await.md
    ├── B_EventLoop.md
    ├── B_Module.md
    ├── CORS(Cross-Origin Resource Sharing).md
    ├── CSS 애니메이션 vs JS 애니메이션.md
    ├── CallByReference.md
    ├── EventLoop.md
    ├── EventLoop_Advanced.md
    ├── Funtional.md
    ├── Higher_Order_Functions.md
    ├── Javascript_BuildTool.md
    ├── Module.md
    ├── Promise1.md
    ├── Promise2.md
    ├── Reactive.md
    ├── Repaint와 Reflow.md
    ├── WebWorker.md
    ├── animation.md
    ├── setState.md
    ├── 기본적인 렌더링 최적화 방법.md
    ├── 웹 브라우저의 작동 원리.md
    └── 점진적향상_우아한하향.md
├── Design_Pattern
    ├── Composite.md
    ├── JSP model.md
    ├── MSA.md
    ├── MVC1, MVC2.md
    ├── MVC_MVP_MVVM.md
    ├── Memoization.md
    ├── RxJS.md
    ├── Singleton.md
    └── Throttle and Debounce.md
├── ECMAScript
    ├── ArrowFunction.md
    ├── Destructuring_Assignment.md
    ├── ECMA2019.md
    ├── ES6-module-in-Browser.md
    ├── Generator와 async-await.md
    ├── Includes_IndexOf.md
    ├── Iteration_Protocol.md
    ├── ModulePattern_class.md
    ├── Number_isNaN.md
    ├── Spread_Operator.md
    └── Tagged_Template_Literals.md
├── Git
    └── gitBy_.git.md
├── HTML
    ├── ARIA.md
    ├── DOM API.md
    ├── DOM.md
    ├── HTML-Templating.md
    ├── Head_Meta.md
    ├── Standard&QuirksMode.md
    ├── WebM&WebP.md
    ├── input태그의_value바꾸기(input태그의_dirty flag).md
    ├── preload&prefetch.md
    └── 웹 컴포넌트(Web Component).md
├── Java
    ├── ArrayList vs LinkedList 그리고 Vector.md
    ├── Comparable vs Comparator.md
    ├── Dependency Injection(DI).md
    ├── JSP와 Servlet처리.md
    ├── JVM(Java Virtual Machine).md
    ├── Java Garbage Collection(GC).md
    ├── Mybatis.md
    ├── Set.md
    ├── String, StringBuilder, StringBuffer.md
    ├── String,StringBuilder, StringBuffer차이.md
    ├── Upcasting과 Downcasting.md
    ├── WAS.md
    ├── copy-object.md
    ├── date-api-in-java.md
    └── junit-setup.md
├── Javascript
    ├── Ajax.md
    ├── Animation.md
    ├── B_Async.md
    ├── B_Call_Apply_Bind.md
    ├── B_Callback.md
    ├── B_Class.md
    ├── B_Function.md
    ├── B_Type.md
    ├── Build Tool.md
    ├── CallStack.md
    ├── Closure.md
    ├── Control_CSSOM.md
    ├── DocumentFragment.md
    ├── Event Delegation.md
    ├── InsertAdjacentHTML.md
    ├── JavaScript의 this.md
    ├── Javascript_Engine.md
    ├── Javascript_메모리관리.md
    ├── Javascript의_동작원리-변수객체(VariableObject).md
    ├── Javascript의_동작원리-실행컨텍스트(Execution Contexts).md
    ├── Jest.md
    ├── Learning_more_about_this.md
    ├── Module.md
    ├── MouseEvent.md
    ├── Object.create&Object.assign.md
    ├── Observer.md
    ├── Optional_Chaining.md
    ├── PromisePattern.md
    ├── Prototype_Chain.md
    ├── Proxy.md
    ├── Reduce.md
    ├── Redux State 정규화.md
    ├── Regular_Expressions.md
    ├── Scope.md
    ├── Some_Every.md
    ├── Storybook.md
    ├── Sync&Async_Multi&Single_Thread.md
    ├── TimeInJS.md
    ├── Variable.md
    ├── WebRTC.md
    ├── Web_Storage_API.md
    ├── ajax(2).md
    ├── bind.md
    ├── object.md
    ├── object_create_pattern-constructor.md
    ├── object_생성패턴.md
    ├── prototype(2).md
    ├── prototype.md
    ├── scope_this.md
    ├── throttling과 rAF.md
    ├── tricks_of_js.md
    ├── underscore와 lodash그리고 Native.md
    ├── window.history.md
    ├── 논리연산자.md
    ├── 렉시컬_속이기(eval).md
    ├── 배열 내장함수.md
    ├── 상태관리 라이브러리.md
    ├── 이벤트 루프(Event Loop).md
    ├── 클래스(class).md
    ├── 클로저.md
    └── 함수 선언.md
├── LICENSE
├── Language
    ├── Currying.md
    ├── Lamda.md
    ├── Reactive.md
    ├── XML_JSON.md
    ├── 고차함수(High Order Function).md
    └── 함수형 프로그래밍.md
├── ML
    └── 머신러닝이란.md
├── Network
    ├── 3-way handshaking & 4-way handshaking.md
    ├── CORS.md
    ├── DHCP&DNS.md
    ├── Flow control.md
    ├── HTTP3.md
    ├── IP.md
    ├── JSend.md
    ├── OSI7 Layer.md
    ├── REST API.md
    ├── REST.md
    ├── SOAP API.md
    ├── Subnetmask.md
    ├── Switch.md
    ├── TCP & UDP.md
    ├── TypesOfIP.md
    ├── comet.md
    ├── congestion control.md
    ├── get&post.md
    ├── http-caching.md
    ├── 로드밸런싱 & 클러스터링.md
    └── 사용자 인증 방식(Cookie, Session & oAuth 2.0 & JWT).md
├── Node.js
    ├── make_meta_file.md
    └── nodejs의_특징.md
├── OpenCV
    └── 이미지전처리.md
├── Performance
    ├── DeadLock(교착상태).md
    ├── HTTP2.0의 필요성.md
    ├── Reflow Repaint.md
    ├── Throttling vs Debouncing.md
    ├── requestAnimationFram(rAF).md
    ├── 기본적인 렌더링 최적화 방법.md
    ├── 서버 사이드 렌더링(SSR).md
    └── 점진적향상_우아한하향.md
├── README.md
├── React
    ├── Component, Props, State.md
    ├── Composition.md
    ├── Element와 Component.md
    ├── ImmutableState.md
    ├── React Server Components.md
    ├── React.memo.md
    ├── React의 Lifecycle Event.md
    ├── SWR.md
    ├── Virtual DOM.md
    └── props와 state.md
├── Rules
    ├── Commit.md
    └── Markdown.md
├── Security
    ├── HTTPS와 SSL.md
    ├── Response_Header_Security.md
    ├── SQL_Injection.md
    └── 리만가설과 소수정리.md
├── Tool
    ├── Chrome_80_DevTool.md
    ├── Framework vs Library.md
    └── Package Manager.md
├── Typescript
    ├── 인터페이스(Interface).md
    ├── 정적 타이핑.md
    ├── 제네릭(Generic).md
    └── 클래스(class).md
├── Vue
    └── Vue_LifeCycle.md
├── WPF
    └── wpf.md
└── assets
    ├── IndexDB
        ├── TodoList
        │   ├── index.html
        │   ├── js
        │   │   ├── indexDB.js
        │   │   └── todo.js
        │   └── todoStyle.css
        └── index2.html
    ├── TEST
        ├── bigfile.html
        ├── img_css_image_sprites.png
        └── window.history.demo.html
    ├── gif
        ├── MobileCSS.gif
        ├── MobileDock.gif
        └── MobileLayout.gif
    └── images
        ├── CallByValue.png
        ├── Collection_Hierarchies.png
        ├── EventLoop.png
        ├── Functional_Programming_Main.png
        ├── Gecko.jpg
        ├── Graph-그래프.png
        ├── Graph-리스트_무향.png
        ├── Graph-리스트_유향.png
        ├── Graph-보행.png
        ├── Graph-종류.png
        ├── Graph-쾨니헤스베르크_다리.png
        ├── Graph-크기.png
        ├── Graph-행렬.png
        ├── HTML-Templating1.png
        ├── HTML-Templating2.png
        ├── HTML-Templating3.png
        ├── HTMLCollection.png
        ├── HashTable.png
        ├── LongPolling.png
        ├── Parent_Child_workflow.png
        ├── SQL_Injection_1.png
        ├── SQL_Injection_2.png
        ├── ScopeChain.png
        ├── ServletClass.png
        ├── Sync&Async_Multi&Single_Thread_1.jpg
        ├── Vue-lifecycle.png
        ├── Webkit.png
        ├── ajax.png
        ├── array_list.png
        ├── bucket-sort.png
        ├── call-by-sharing01.png
        ├── coalescing.png
        ├── compaction.png
        ├── compilerDesign.jpg
        ├── copy-object01.png
        ├── event_delegation.png
        ├── event_loop.jpeg
        ├── event_loop_gif.gif
        ├── flux_architecture.png
        ├── get&post.png
        ├── gitBy_.git_gitlifecycle.png
        ├── gitBy_.git_gitobjects.png
        ├── https_asymmetric_key.png
        ├── hystrix.png
        ├── insertAdjacentHTML_1.PNG
        ├── insertAdjacentHTML_2.PNG
        ├── insertAdjacentHTML_3.PNG
        ├── java_Runtime_Data_Areas.jpg
        ├── java_gc_heap.png
        ├── java_gc_object.png
        ├── java_runtime_data_area.png
        ├── javascript의_동작원리-실행컨텍스트(ExecutionContexts)-1.png
        ├── javascript의_동작원리-실행컨텍스트(ExecutionContexts)-2.png
        ├── linked_list.png
        ├── memoryHier.png
        ├── memorymodel.png
        ├── non-blocking.png
        ├── non-linear-search-bfs.png
        ├── non-linear-search-dfs.png
        ├── non-linear-search.gif
        ├── page_pageframe.png
        ├── polling.png
        ├── preflight-process.png
        ├── primitiveCasting.png
        ├── prototype1.png
        ├── prototype2.png
        ├── react_lifecylce.png
        ├── rendering.png
        ├── segmentation.png
        ├── server_side.png
        ├── servletArchitecture.png
        ├── streaming.png
        ├── typescript_access_modifier.png
        ├── typescript_type.png
        ├── was1.png
        ├── was2.png
        ├── was3.png
        └── was4.png


/.github/workflows/action.yml:
--------------------------------------------------------------------------------
 1 | name: "Pull Request Action"
 2 | on: 
 3 |   pull_request:
 4 |     types: [opened]
 5 | 
 6 | jobs:
 7 |   test:
 8 |     runs-on: ubuntu-latest
 9 |     steps:
10 |     - name: Create link
11 |       uses: Im-D/Im-Bot/packages/pr-supporter@master
12 |       with:
13 |         myToken: ${{ secrets.GITHUB_TOKEN }}
14 |     - name: Create reviewRequest
15 |       uses: Im-D/Im-Bot/packages/pr-reviewer@master
16 |       with:
17 |         myToken: ${{ secrets.GITHUB_TOKEN }}
18 |     - name: Create Link at README file
19 |       uses: Im-D/Im-Bot/packages/update-readme@master
20 |       with:
21 |         myToken: ${{ secrets.GITHUB_TOKEN}}
22 |         linkLocTarget: '### 📅 History'


--------------------------------------------------------------------------------
/.mergify.yml:
--------------------------------------------------------------------------------
 1 | pull_request_rules:
 2 |   - name: Automatic merge on review
 3 |     # https://doc.mergify.io/examples.html#require-all-requested-reviews-to-be-approved
 4 |     conditions:
 5 |       - "#approved-reviews-by>=4"
 6 |       - "#changes-requested-reviews-by=0"
 7 |       - base=master
 8 |       - label=approval + 3
 9 |     actions:
10 |       merge:
11 |         method: merge
12 |       delete_head_branch: {}
13 | 
14 |   - name: Add Label needs author response
15 |     conditions:
16 |       - "#changes-requested-reviews-by>=1"
17 |     actions:
18 |       label:
19 |         add: ["needs author response"]
20 |         remove: ["needs review"]
21 | 
22 |   - name: Remove Label needs author response
23 |     conditions:
24 |       - "#changes-requested-reviews-by=0"
25 |     actions:
26 |       label:
27 |         add: ["needs review"]
28 |         remove: ["needs author response"]
29 | 
30 |   - name: Add Label approval + 1
31 |     conditions:
32 |       - "#approved-reviews-by=1"
33 |     actions:
34 |       label:
35 |         add: ["approval + 1"]
36 | 
37 |   - name: Add Label approval + 2
38 |     conditions:
39 |       - "#approved-reviews-by=2"
40 |     actions:
41 |       label:
42 |         add: ["approval + 2"]
43 |         remove: ["approval + 1"]
44 |   - name: Add Label approval + 3
45 |     conditions:
46 |       - "#approved-reviews-by=3"
47 |     actions:
48 |       label:
49 |         add: ["approval + 3"]
50 |         remove: ["approval + 2"]
51 | 


--------------------------------------------------------------------------------
/Browser/FOUC.md:
--------------------------------------------------------------------------------
 1 | # FOUC(Flash of Unstyled Content)
 2 | 
 3 | `FOUC(Flash of Unstyled Content)`란 브라우저에서 웹 페이지에 접근했을 때, 미처 스타일이 적용되지 못한 상태로 화면이 나타나는 현상을 말한다. 
 4 | 
 5 | 스타일이 적용되기 전의 상태가 먼저 화면에 렌더링된 후 그 상태에서 스타일이 적용되기 때문에 스타일이 적용되는 과정이 사용자에게 그대로 노출되는 현상이다. 이러한 현상은 사용자의 경험(UX)를 떨어트리게 된다는 문제가 있다.
 6 | 
 7 | `FOUC`는 특히 `IE(Internet Explorer)` 브라우저에서 주로 발생되며 `IE11`에서도 여전히 발생되고 있는 문제다.
 8 | 
 9 | ## FOUC의 발생 원인
10 | 
11 | `FOUC`의 발생 원인은 다양하지만 몇 가지만 우선적으로 살펴보면 다음과 같다.
12 | 
13 | ### CRP(Critical Rendering Path)
14 | 
15 | ![Webkit](https://user-images.githubusercontent.com/24724691/62412567-bf49f200-b63f-11e9-9ed4-ec8215d04a7d.png)
16 | 
17 | 위처럼 브라우저에서 화면이 그려지기까지의 주요한 과정을 `CRP(Critical Rendering Path)`라고 한다.
18 | 
19 | 1. HTML 마크업을 처리하고 DOM 트리를 빌드한다.
20 | 2. CSS 마크업을 처리하고 CSSOM 트리를 빌드한다.
21 | 3. DOM 및 CSSOM을 결합하여 Rendering 트리를 형성한다.
22 | 4. Rendering 트리에서 레이아웃을 실행하여 각 노드의 기하학적 형태(화면의 위치)를 계산한다.
23 | 5. 개별 노드를 화면에 paint한다.
24 | 
25 | `Render Tree`가 노출된 후 CSS와 JS 파일등으로 변경되면 이 변경 사항들이 화면에 노출될 수 있다. 이 현상이 `FOUC`다.
26 | 
27 | 웹 브라우저의 작동 원리에 대해 좀 더 자세히 알고 싶다면 [다음](https://github.com/im-d-team/Dev-Docs/blob/master/Browser/%EC%9B%B9%20%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EC%9D%98%20%EC%9E%91%EB%8F%99%20%EC%9B%90%EB%A6%AC.md)을 참고하길 바란다.
28 | 
29 | 최근의 웹 페이지들은 여러 개의 CSS 파일을 참조하거나 웹 폰트를 사용함으로써 DOM 구조를 변경하기 때문에 더욱 자주 발생할 수 있는 환경이다.
30 | 
31 | ### `@import`를 사용한 CSS 
32 | 
33 | IE(Internet Explorer)를 제외한 브라우저의 경우, 참조(`@import`)되는 스타일이 적용될때까지 화면에 표시하지 않는다. 하지만, IE의 경우 화면에 노출된 상태로 스타일이 적용되어 FOUC를 유발한다.
34 | 
35 | ### 웹 폰트의 사용
36 | 
37 | 이또한 `@import`를 사용하여 스타일링을 할 때와 같은 원리로 `FOUC`가 발생하게 된다. IE는 웹 폰트를 사용할 경우 기본 폰트를 불러들이고 이를 사용된 웹 폰트로 다시 재변경되게 되는데 이 과정을 그대로 화면에 노출시키게 된다.
38 | 
39 | ## FOUC 해결
40 | 
41 | ### JS import 위치 변경
42 | 
43 | 일반적으로 자바스크립트를 선언할 때는 성능을 위해 `</body>` 태그 바로 위에 위치시키곤 한다.
44 | 하지만 이를 `<head>`태그 안으로 위치시킴으로써 `FOUC`를 개선할 수 있다. 하지만 이 방법으로는 웹 폰트나 `@import`를 사용한 CSS로 인한 `FOUC` 발생을 막을 수는 없다.
45 | 
46 | ### FOUC 발생 위치의 컴포넌트 숨기기
47 | 
48 | `@import` 사용으로 인한, 웹 폰트로 인한 `FOUC`발생을 막기 위해서는 `FOUC`가 발생하는 위치의 컴포넌트를 숨겼다가 웹 폰트 혹은 참조(`@import`) CSS의 로딩이 완료되면 보여주는 방법이 있다. 물론, 숨기는 것은 한 예시일 뿐이고 로딩바를 보여준다거나 스켈레톤 UI를 보여준다거나 할 수 있다.
49 | 
50 | ```html
51 | <html class="no-js">
52 |   <head>
53 |     <style>
54 |       .js #fouc {
55 |         display: none
56 |       }
57 |     </style>
58 |     <script>
59 |       (function (H) {
60 |         H.className = H.className.replace(/\bno-js\b/, 'js')
61 |       })(document.documentElement)
62 |       </script>
63 |   </head>
64 | 
65 |   <body>
66 |     <div id="fouc">
67 |       FOUC 발생 지점
68 |     </div> <!-- /#fouc -->
69 |     <script>
70 |       document.getElementById("fouc").style.display = "block";
71 |     </script>
72 |   </body>
73 | </html>
74 | ```
75 | [소스 출처 - webdir.tistory.com](https://webdir.tistory.com/416)
76 | 
77 | 위 소스에 대해 간단히 설명하면 자바스크립트와 CSS 스타일이 모두 로딩되었을 경우, `fouc` ID를 가진 컴포넌트를 렌더링시켜준다.
78 | 
79 | `FOUC`의 발생은 최근에는 대부분 `IE`에서 발생하기 때문에 `IE`에 대해서만 분기 처리를 한 후 `FOUC`에 대한 처리를 하는 것도 좋은 방법이 될 수 있다.
80 | 
81 | ---
82 | 
83 | #### Reference
84 | 
85 | - [화면 깜빡임(FOUC) 문제해결](https://webdir.tistory.com/416)
86 | - [UZULAB - #3 FOUC, 화면 깜박임 문제](https://uzulab.tistory.com/4)
87 | 


--------------------------------------------------------------------------------
/Browser/HTTP2_Websocket.md:
--------------------------------------------------------------------------------
  1 | # HTTP2.0과 Web Socket
  2 | 
  3 | ## HTTP란
  4 | 
  5 | HTTP는 HyperText Transfer Protocol의 약자다. Request와 Response로 이루어진 통신 규약이다.
  6 | 
  7 | 이 HTTP의 단점 중 하나는 Request가 있어야만 Response가 존재한다는 점이다. 이 요청은 URL로 이루어져 새로운 요청을 보내려면 새로운 페이지가 필요하다. 예를들어 회원가입시 ID 중복확인을 하려면 새 페이지로 넘어가야 한다.
  8 | 
  9 | 또한 페이스북처럼 정보를 거의 실시간으로 확인 할 수 있는 SNS의 경우, 정보의 갱신이 매우 빠르게 일어나는데 이를 업데이트 하려면 항상 클라이언트의 Request가 필요하다. 만약 이 경우 서버의 정보가 갱신되지 않았다면 통신의 낭비가 일어나기도 한다.
 10 | 
 11 | HTTP의 대표적인 단점으로는
 12 | 
 13 | - 1개의 커넥션에 1개의 리퀘스트만 가능하다.
 14 | - Request는 클라이언트 사이드에서만 시작할 수 있다.
 15 | - 헤더가 압축되지 않는다.
 16 | - 우선순위가 없다.
 17 | 
 18 | 등 다양하다.
 19 | 
 20 | ## 문제해결
 21 | 
 22 | 이러한 문제들중 몇가지를 해결하기 위해 등장한 것이 AJAX와 COMET방식이다.
 23 | 
 24 | ### AJAX
 25 | 
 26 | ---
 27 | 
 28 | 구글의 AJAX는 HTTP 통신을 사용은 하지만 HttpRequst가 아닌 XMLHttpRequest를 사용하여 새로운 HTML을 사용하지 않고 페이지의 일부만 수정할 수 있게 된다.
 29 | 
 30 | ### COMET
 31 | 
 32 | ---
 33 | 
 34 | Comet은 서버측의 데이터 갱신이 있을때 Request를 기다리지 않고 Response를 보내기 위한 방법이다. Comet의 경우 Request에 따른 Response를 반환하지 않고 보류해둔다. 그 뒤 서버의 데이터가 갱신되면 Response를 반환하는 방식이다. 롱폴링(long polling)방식이라고도 한다.
 35 | 
 36 | 위의 두가지 방법은 모두 프로토콜 레벨의 방법은 아니며 HTTP가 가진 근본적인 단점을 해결해 줄 수는 없다.
 37 | 
 38 | ## SPDY
 39 | 
 40 | 느린 HTTP를 해결하기 위해 나온 것이 SPDY다. 구글이 시도했던 실험 프로토콜이다. Page Load Time을 50%로 줄이기 위함이 목표였다.
 41 | 
 42 | 핵심적인 변화는 이러하다. 기존의 데이터는 플레인 텍스트로 통신을 하였는데 이를 바이너리로 인코딩하여 **프레임** 이라는 단위로 변경하여 전송한다. 즉 하나의 chunk에서 frame이라는 단위로 쪼개기가 가능해진다. 이를 통해 요청/응답 다중화, 우선순위 지정 및 헤더 압축이 목표였다.
 43 | 
 44 | 이게 2012년의 이야기이며 이를 본 HTTP-WG(HTTP Working Group)이 HTTP2.0을 만든다.
 45 | 
 46 | 이 HTTP2.0은 SPDY의 사양을 채택해 출발하게 되고 2015년 SPDY는 지원을 중단하며 HTTP2.0으로 사실상 통합되게 된다.
 47 | 
 48 | ## Web Socket
 49 | 
 50 | 2014년 HTML5의 등장과 함께 Web Socket이 등장한다.
 51 | 
 52 | HTTP와 같이 Web Socket은 프로토콜이며 양방향 소통을 지원하는 프로토콜이다. HTTP가 가진 근본적인 문제 중 하나인 **Request는 클라이언트 사이드에서만 시작할 수 있다.** 를 완전히 해결할 수 있는 프로토콜이다.
 53 | 
 54 | 시작점은 클라이언트에게 있지만 처음 HTTP로 연결한 뒤 그 뒤로는 WebSocket 프로토콜을 이용하여 양쪽 모두 송신이 가능하게 된다.
 55 | 
 56 | 또한 처음 HTTP 통신 이후에는 헤더의 사이즈를 감소시켜 통신량을 줄이게 된다.
 57 | 
 58 | ## HTTP 2.0
 59 | 
 60 | HTTP 2.0의 도입배경은 SPDY를 통해 소개를 했다.
 61 | 
 62 | 핵심적인 변화로는 Binary Framing부터 시작한다. 새로운 메커니즘으로 아래와 같은 구조를 가진다.
 63 | 
 64 | - 스트림(바이트의 흐름)
 65 | - 메시지(전체 시퀀스며 Request / Response의 단위다.)
 66 | - 프레임(통신의 최소단위)
 67 | 
 68 | 프레임이 모여 메시지가 되고 메시지가 모여 스트림이 된다.
 69 | 
 70 | 장점을 알아보자
 71 | 
 72 | ### 요청 및 응답 다중화
 73 | 
 74 | ---
 75 | 
 76 | 프레임은 헤더나 메시지 페이로드 등을 전송하며 **인터리빙**이 가능하다. 즉 데이터를 읽을 때 순서대로가 아니게 읽는 것이 가능하며 대역폭 증가의 효과를 가진다.
 77 | 
 78 | 인터리빙으로 병렬처리가 가능해지면서 통신 단위의 변경이 가능해집니다.
 79 | 
 80 | HTTP 1.0은 기존의 메시지가 단위였다면 2.0부터는 스트림이 단위가 된다. 따라서 동시에 여러 메시지를 처리할 수 있게 되고 Request의 순서와 상관없이 Response를 보낼 수 있게 되었다.
 81 | 
 82 | HTML 파싱 시 여러 Request가 필요한데 이것의 순서가 없어져 Response를 기다려야하는 통신의 낭비가 사라진다.
 83 | 
 84 | ### 우선순위 지정
 85 | 
 86 | ---
 87 | 
 88 | 인터리빙에 따른 병렬처리로 서버와 클라이언트측에 각각 요청이 전달되는 순서가 성능 이슈로 떠오릅니다. 따라서 가중치를 통해 우선순위를 줄 수 있게 됩니다.
 89 | 
 90 | ### 서버푸쉬
 91 | 
 92 | ---
 93 | 
 94 | 서버푸쉬는 웹소켓과는 다른 개념이다.
 95 | 
 96 | 예를들어 초기 페이지에 index.html만이 아니라 많은 css, js, image파일과 같은 추가적인 리소스가 필요하다면 이를 클라이언트가 요청하지 않아도 서버가 푸쉬할 수 있는 방식이다.
 97 | 
 98 | ### 헤더압축
 99 | 
100 | ---
101 | 
102 | 기존의 HTTP는 헤더를 항상 일반텍스트로 보냈다.
103 | 이를 HTTP 2.0에서는 HPACK 압축방식을 이용하여 보내게끔 되어있다.
104 | 


--------------------------------------------------------------------------------
/CS/Memory.md:
--------------------------------------------------------------------------------
 1 | # Memory
 2 | 
 3 | 메모리는 말그대로 저장소다. 뭔가를 하려면 어떤 데이터를 어떻게 처리하라고 한다. 즉 데이터와 처리명령 두가지가 필요하다.
 4 | 
 5 | 그래서 메모리도 두 영역으로 나뉘어 있다. Program / Data 부분이 나뉜다.
 6 | 
 7 | ## 메모리 계층구조
 8 | 
 9 | 메모리는 당연히 빠를수록 비싸다. 그래서 빠르고 비싼 메모리는 용량이 작다. 반대로 느리면서도 싼 메모리는 용량이 크다. 아주 쉽게 생각할 것은 HDD와 SSD의 차이를 생각해보면 된다.
10 | 
11 | ![memoryHierachy](/assets/images/memoryHier.png)
12 | 
13 | 그래서 위와 같은 그림이 나온다. 레지스터와 캐시는 CPU 내부에 존재한다. 그만큼 작고 빠르다. Cache는 SRam과 같다. Memory는 Dram이다. 흔히 RAM 이라고 부른다. 8GB DDR4 램 사면 이거다. Disk는 하드디스크 그거다.
14 | 
15 | 보통 레지스터, 캐시, 메모리를 주 기억장치, 디스크를 보조 기억장치라고 부른다. 주 기억장치는 보조보다는 빠르나 전원을 끄면 데이터가 날아간다.(휘발성)
16 | 
17 | ## 메모리 구조
18 | 
19 | 메모리는 다음 그림과 같이 공간을 나누어 관리한다.
20 | 
21 | ![memoryModel](/assets/images/memorymodel.png)
22 | 
23 | 그림에 따라 low address와 high address가 반대가 되어 스택이 쌓이는 구조로 보이기도 한다. 그러나 중요한 점은 메모리는 사용용도에 따라 구역을 나누어 관리하고 순서가 있다는 점이다.
24 | 
25 | ### TEXT
26 | 
27 | 프로그램 코드가 저장되는 영역이다. 따라서 코드영역이라고도 불린다. 물론 개발자가 작성한 소스코드는 아니고 기계어로 저장된다.
28 | 
29 | Read-Only Data다. CPU가 이 영역의 데이터를 fetch해서 실행한다.
30 | 
31 | ### DATA(GVAR + BSS)
32 | 
33 | 전역변수, static 변수가 저장되는 공간이다.
34 | 
35 | 초기화된 데이터는 data 영역에 저장되고, 초기화 되지 않은 데이터는 BSS(Block Stated Symbol)영역에 저장된다.
36 | 
37 |     js의 var let const의 호이스팅 시 선언, 초기화, 할당에 관한 내용 중 초기화와 관련한 내용이지 않을까 싶다.
38 |     let과 const는 선언만 되며 초기화가 되지않아 메모리에 없다.
39 |     그런데 js는 전역 스코프 역시 객체다. 그럼 참조타입이라 heap에 저장될 것 같다.
40 |     실행 컨텍스트와 관련된 내용같은데 자세히 좀 더 알아보자
41 | 
42 | 프로그램이 실행될 때만 생성되고 종료시 반환하는 영역이다.
43 | 
44 | ### HEAP
45 | 
46 | 흔히 참조타입이 저장된다. 이 영역에 저장하기 위해 `new` 키워드를 사용한다.
47 | 
48 | 개발자가 임의로 만들 수 있는 영역이라 동적 할당영역이라고 부른다.
49 | 
50 | HEAP을 참조하는 영역이 없으면 GC가 돌면서 마킹을 통해 제거하는 영역이다.
51 | 
52 | ### STACK
53 | 
54 | 지역변수, parameter, 리턴 값 등이 임시로 저장되었다가 사라지는 영역입니다.
55 | 
56 | 원시 값 타입이 저장되는 공간입니다.
57 | 
58 | stack은 함수 호출 시 할당되며 함수 종료(return)시 제거됩니다.
59 | 
60 | 엄격하게 LIFO가 지켜집니다. 이렇게 스택에 저장되는 호출정보를 stack frame이라고 합니다. 흔히 우리가 부르는 call stack은 stack frame과 연관이 있습니다.
61 | 
62 | ### 흐름
63 | 
64 | 1. 개발자가 소스코드를 완성하여 컴파일 => 실행단계가 되면 코드는 TEXT에 올라간다.
65 | 2. 프로그램이 실행되면 프로그램은 프로세스가 된다.(프로세스 == 실행중인 프로그램)
66 | 3. 프로세스의 흐름에 따라 DATA영역에 전역과 static변수를 만든다.
67 | 4. 코드의 흐름에따라 HEAP과 STACK영역을 움직이며 메모리를 사용한다.
68 | 5. 프로그램이 종료되면 DATA영역을 반환한다.
69 | 
70 | ### 문제
71 | 
72 | 너무 자주 봐왔고, 참조변수와 포인터에 관한 이야기다.
73 | 
74 | ```js
75 | const arr = [1, 2, 3];
76 | 
77 | const foo = arr => {
78 |   arr[1] = 100;
79 |   arr = [4, 5, 6];
80 | 
81 |   console.log(arr);
82 | };
83 | 
84 | foo(arr);
85 | 
86 | console.log(arr);
87 | ```
88 | 
89 | 어떻게 나올지는 항상 언제 물어봐도 메모리 그림을 그려 대답할 수 있도록 하자.
90 | 
91 | ### 참고자료
92 | 
93 | - [메모리 저장구조 이해하기](https://m.blog.naver.com/PostView.nhn?blogId=itperson&logNo=220821884483&proxyReferer=https%3A%2F%2Fwww.google.com%2F)
94 | - [TCP school 메모리의 구조](http://tcpschool.com/c/c_memory_structure)
95 | 


--------------------------------------------------------------------------------
/CS/Radix-sort.md:
--------------------------------------------------------------------------------
 1 | # 기수 정렬(Radix Sort)
 2 | 
 3 | 비교(comparison) 기반 정렬 알고리즘의 가장 낮은 복합도는 `O(nlogn)` 이다.
 4 | 
 5 | 반면 계수 정렬(counting sort)은 선형 시간 정렬 알고리즘이다. 검색 대상의 범위가 1부터 k까지라고 할 때 `O(n+k)` 의 복합도를 가진다.
 6 | 
 7 | > [선형 시간(lineart time)](https://ko.wikipedia.org/wiki/%EC%84%A0%ED%98%95_%EC%8B%9C%EA%B0%84) : 계산 복잡도 이론에서 입력된 길이 n에 대하여 실행시간이 `O(n)` 이 되는 것
 8 | >
 9 | > 참고 : [계수 정렬](https://github.com/Im-D/Dev-Docs/blob/master/CS/Counting-sort.md)
10 | 
11 | 하지만 대상의 범위 k가 n^2 보다 커질 경우 `O(n^2)` 이상의 복잡도를 가지게 된다. 이는 비교 기반 정렬 알고리즘보다 성능이 좋지 않다.
12 | 
13 | 이런 경우 기수 정렬을 통해 선형 시간을 갖는 정렬을 할 수 있다. 
14 | 
15 | ## 수행과정
16 | 
17 | 기수 정렬은 각 자릿수마다 순차적으로 정렬하는 방식이다. 
18 | 
19 | 10진수를 사용한다면 각 자릿수는 최소 0에서 최대 9까지의 값만 나올 수 있다.
20 | 
21 | 따라서 각 자릿수 마다 계수 정렬을 실행한다면, 계수 정렬 대상의 수는 항상 10 이하로 정해진다.
22 | 
23 | > 계수 정렬을 사용하기 때문에 부동 소수점은 정렬이 불가능하다.
24 | 
25 | 수행과정은 다음과 같다.
26 | 
27 | ```java
28 | // 정렬 대상
29 | int arr[] = {170, 45, 75, 90, 802, 24, 2, 66};
30 | int max = 정렬 대상의 최대값
31 |     
32 | for (자릿수 = 1; max/자릿수 > 0; 자릿수 *= 10) {
33 | 	계수정렬 실행
34 | } 
35 | ```
36 | 
37 | > 참고 :  [수행과정 - Radix Sort | GeeksforGeeks](https://youtu.be/nu4gDuFabIM?t=18)
38 | 
39 | 
40 | 
41 | 자릿수의 개수만큼 반복해야하기 때문에 최고 자릿수가 `d` 일 때 기수 정렬의 시간 복잡도는 `O(dn)` 이다. 예를 들어, 가장 큰 수가 10000이라면, 최고 자릿수가 5이기 때문에 `O(5n)` 이 된다.
42 | 
43 | 따라서 특정 조건을 만족하면 아주 빠른 알고리즘이지만, 자릿수 만큼의 저장 공간이 추가로 발생하기 때문에 공간 복잡도가 좋지 않다.
44 | 
45 | ## 기수 정렬의 다른 방법
46 | 
47 | 위에서 알아본 계수 정렬 방법은 일반적인 방법으로 가장 오른쪽 부터 시작하는 LSD radix sort이다. 반대로 가장 왼쪽 부터 시작하는 경우는 MSD라고 한다.
48 | 
49 | > LSD(Least Significant Digit; 최하위 자릿수)
50 | >
51 | > MSD(Most Significant Digit; 최대 자릿수)
52 | 
53 | LSD의 경우 stable하지만, MSD는 stable 하지 않다. 따라서 기수 정렬의 서브루틴으로 계수 정렬을 사용하기 위해서는 LSD를 사용해야한다.
54 | 
55 | LSD는 모든 자릿수를 정렬해야 정렬된 결과를 얻을 수 있지만, MSD의 경우 중간에 정렬이 완료될 수 있다. 하지만 이를 위해 추가적인 연산과정과 메모리가 필요하다. 자세한 사항은 다음을 참고하자.
56 | 
57 | > 참고 : [In-place MSD radix sort implementations - wikipedia](https://en.wikipedia.org/wiki/Radix_sort#In-place_MSD_radix_sort_implementations)
58 | 
59 | ### 버킷 정렬(bucket sort)
60 | 
61 | 이외에도 큐 혹은 버킷을 이용하여 기수 정렬을 구현하는 경우가 있다. 이는 버킷 정렬을 사용한다.
62 | 
63 | ![bucketsort](../assets/images/bucket-sort.png)
64 | 
65 | 버킷 정렬은 정렬 대상의 값들이 일정하게 분포되어 있을 때 효과적인 방법이다.
66 | 
67 | 값의 분포에 따라 특정 범위를 지정한다. 이 때, 지정한 범위가 버킷이다.
68 | 
69 | 범위에 해당되는 값들을 각 버킷에 담고 버킷 내의 값들을 정렬하는 방법이다.
70 | 
71 | 이 때, 버킷 내의 값들은 버킷 정렬을 반복하여 적용시키거나, 다른 알고리즘을 사용하여 정렬한다.
72 | 
73 | 이러한 원리를 이용하여 기수 정렬을 병렬 컴퓨팅에 적용하는 경우도 있는데 이는 다음을 참고하자
74 | 
75 | > 참고 
76 | >
77 | > - [Application to parallel computing - wikipedia](https://en.wikipedia.org/wiki/Radix_sort#Application_to_parallel_computing)
78 | > - [Fastest sorting algorithm for distributed systems (Parallel Radix Sort) [Difficulty: Medium]](https://summerofhpc.prace-ri.eu/fastest-sorting-algorithm-for-distributed-systems-parallel-radix-sort-difficulty-medium/)
79 | 
80 | ---
81 | 
82 | References
83 | 
84 | - [Bucket Sort - GeeksforGeeks](https://www.geeksforgeeks.org/bucket-sort-2/)
85 | - [What are the differences between radix sort and bucket sort? - Quora](https://www.quora.com/What-are-the-differences-between-radix-sort-and-bucket-sort)
86 | - [Radix Sort - BRILLIANT](https://brilliant.org/wiki/radix-sort/)
87 | - [Radix sort - wikipedia](https://en.wikipedia.org/wiki/Radix_sort)
88 | - [기수 정렬(Radix Sort) - tubuk.tistory.com](https://tubuk.tistory.com/16)
89 | 


--------------------------------------------------------------------------------
/CS/cohension&coupling.md:
--------------------------------------------------------------------------------
 1 | # 응집도(Cohension)와 결합도(Coupling)
 2 | 
 3 | 좋은 프로그램은 높은 응집도와 낮은 결합도를 가진다.
 4 | 
 5 | ## 응집도 
 6 | 
 7 | 응집도는 모듈 내부의 기능적인 응집 정도를 뜻한다. 이상적인 응집도는 모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 것이다. 응집도는 클 수록 좋다.
 8 | 
 9 | * 기능적 응집도(Functional Cohesion)
10 |   * 모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우
11 | * 순차적 응집도(Sequential Cohesion)
12 |   * 모듈 내에서 한 활동으로 부터 나온 출력값을 다른 활동이 사용할 경우
13 | * 교환적 응집도(Communication Cohesion)
14 |   * 동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여있을 경우
15 | * 절차적 응집도(Procedural Cohesion)
16 |   * 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성요소들이 그 기능을 순차적으로 수행할 경우
17 | * 시간적 응집도(Temporal Cohesion)
18 |   * 연관된 기능이라기 보단 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리할 경우
19 | * 논리적 응집도(Logical Cohesion)
20 |   * 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우
21 | * 우연적 응집도(Coincidental Cohesion)
22 |   * 모듈 내부의 각 구성요소들이 연관이 없을 경우
23 | 
24 | > 우연적 응집도 < 논리적 응집도 < 시간적 응집도 < 절차적 응집도 < 교환적 응집도 < 순차적 응집도 < 기능적 응집도
25 | 
26 | 위에서 아래로 내려올 수록 응집도가 낮아진다(나빠진다)고 할 수 있다. 기능적 응집도가 이상적인 응집정도이다.
27 | 
28 | ## 결합도
29 | 
30 | 결합도는 의존성 정도이다. 이상적인 결합도는 인터페이스의 파라미터를 통해서만 상호 작용이 일어나며, 파라미터는 값으로 이루어져야 한다. 결합도는 낮을 수록 좋다.
31 | 
32 | * 자료 결합도(Data Coupling)
33 |   * 모듈간의 인터페이스 전달되는 파라미터를 통해서만 모듈간의 상호 작용이 일어나는 경우
34 |   * 깔끔한 Call by value
35 | * 스탬프 결합도(Stamp Coupling)
36 |   * 모듈간의 인터페이스로 배열이나 오브젝트, 스트럭쳐등이 전달되는 경우
37 | * 제어 결합도(Control Coupling)
38 |   * 단순히 처리를 해야할 대상인 값만 전달되는게 아니라 어떻게 처리를 해야 한다는 제어 요소(명령어, Flag등)이 전달되는 경우.
39 | * 외부 결합도(External Coupling)
40 |   * 어떤 모듈에서 반환한 값을 다른 모듈에서 참조해서 사용하는 경우
41 | * 공통 결합도(Common Coupling)
42 |   * 파라미터가 아닌 모듈 밖에 선언되어 있는 전역 변수를 참조하고 전역변수를 갱신하는 식으로 상호작용하는 경우
43 | * 내용 결합도(Content Coupling)
44 |   * 다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용 하는 경우
45 | 
46 | > 자료 결합도 < 스탬프 결합도 < 제어 결합도 < 외부 결합도 < 공통 결합도 < 내용 결합도
47 | 
48 | 위에서 아래로 내려올 수록 결합도가 커진다(나빠진다)고 할 수있다. 자료 결합도가 가장 이상적인 결합정도이다.
49 | 
50 | ---
51 | 
52 | #### References
53 | 
54 | - [응집도(Cohension)](http://itwiki.kr/w/%EC%9D%91%EC%A7%91%EB%8F%84)
55 | - [결합도(Coupling)](http://itwiki.kr/w/%EA%B2%B0%ED%95%A9%EB%8F%84)
56 | 
57 | 


--------------------------------------------------------------------------------
/CS/information_theory.md:
--------------------------------------------------------------------------------
 1 | # 정보이론
 2 | 
 3 | ## 소통
 4 | 
 5 | 소통에는 늘 잡음이 낀다.
 6 | 
 7 | 이웃이 주식으로 돈을 좀 많이 벌었다라는 사실이 있다면 정보는 왜곡되고 과장이 되기 마련이다.
 8 | 그 이웃은 돈을 벌어 집도 사고 차도 새로 뽑는다. 친구의 뒷통수를 쳐 돈을 벌었으며 곧 해외로 도망간단다.
 9 | 
10 | 꼭 소문만이 아니다. 실제로 정보의 통신에는 잡음이 낀다. 무전기로 통신을 할 때 잡음이 생기는걸 생각해보면 된다.
11 | 
12 | 신호는 전송 도중 에너지를 빼앗겨 그 신호가 약해진다. 봉화에 불을 붙이면 가까이선 잘 보이지만 멀리선 당연히 잘 안 보인다.
13 | 
14 | 0과 1로 이루어진 신호 역시 통신시에는 잡음이 생긴다.
15 | 
16 | ## 통신과 잡음
17 | 
18 | 우리가 컴퓨터로 통신할 때 잡음이 생긴다면 어떨까? 내가 1000만원을 송금했는데 잡음이 생겨 0이 하나 빠져 100만원이 송금된다면? 끔찍하다.
19 | 
20 | 그럼 어떻게 메시지를 온전하게 전달할 수 있을까? 정보를 온전히 전달하는 기술은 정보이론에 기초한다. 정보이론은 1948년 클로드 섀년이 그의 나이 32세에 탄생시킨다.
21 | 
22 | ### 잡음에 대한 다른 시각
23 | 
24 | 통신에는 잡음이 생긴다고 했다. 1948년에는 잡음은 물리적인 현상이며 이를 물리(하드웨어, 아날로그)적인 방식으로 어떻게 극복할 수 있을까 고민했다.
25 | 
26 | 메시지 전달속도를 높이려면 주파수를 높이거나, 잡음이 생긴다면 신호를 강하게 만들면 된다거나 하는 방법으로 말이다.
27 | 
28 | 하지만 섀년은 달랐다. 하드웨어가 아니라 소프트웨어(보내려는 메시지)적인 방법으로 해결하고자 했다.
29 | 
30 | ## 정보량
31 | 
32 | 소프트웨어인 메시지에 주목하고자 먼저 한 일은 정보량에 대해 정리하는 일이었다.
33 | 
34 | 정보의 양은 뭘까? 섀넌은 확률을 기준으로 정보량을 정리했다.
35 | 
36 | 예를들어 '하겠습니' 다음에는 '다'가 나올 확률이 '까'가 나올 확률보다 훨씬 높다. '하겠습니다'는 '하겠습니까'보다 자주 나오므로 예측하기 쉽다. 예측하기 쉬우면 정보의 양이 적다.
37 | 
38 | 왜 예측하기 쉬우면 정보의 양이 적을까? 쉽게 장마철을 생각해보자. 장마철에 비가오는건 당연하다. 확률이 높다. 장마철에 내일도 비가 올 것입니다 라는 정보는 그다지 중요하지 않다.
39 | 
40 | 반대로 가뭄에 비가 올 확률은 매우 적다. 한 달 동안 가뭄인 상태에서 내일은 드디어 비가 올 것 같습니다 라는 정보는 훨씬 더 중요하다. 즉 훨씬 더 중요하며 정보량이 많다.
41 | 
42 | 위의 논리라면 알파고의 78수가 나올 확률은 0.007%이며 이는 매우 중요한 정보라는 것이 증명된다.
43 | 
44 | ### 엔트로피
45 | 
46 | 이는 엔트로피의 개념과 같다. 나는 문과 출신이라 엔트로피에 대해 잘 모른다. 쉽게 무질서의 정도라고 한다.
47 | 
48 | 예를들어 문서에 a, b, c, d만 등장하며, 각각의 문자가 등장할 확률이 모두 25%로 같다고 하자. 그렇다면 이 문서의 정보량은 엔트로피의 공식에 의해 2라고 한다.
49 | 
50 | 확률이 모두 같다면 가장 정돈된 상태다. 가장 정돈된 상태가 네 글자로 만들 수 있는 최대 정보량이다. 확률이 달라진다면 어떤 글자가 나올지 예측하기가 쉬워지며 정보의 양이 줄어든다.
51 | '하겠습니' 뒤에는 '다'가 나올 확률이 높으니 정보가 줄어드는 것처럼 영어에는 e가 제일 많이 나와 정보의 양이 줄어든다.
52 | 
53 | 즉 확률이 서로 다르면 무질서한 상태가 된다. 무질서할수록 정보의 양은 줄어든다.
54 | 
55 | ### 정보량과 잡음
56 | 
57 | 아까도 말했듯 통신에는 잡음이 생긴다. 이를 물리적인 방법으로 해결하는 데에는 한계가 있다. 메시지의 강도를 높이면 잡음도 심해지기 때문이다.
58 | 
59 | 섀넌은 통신의 한계는 물리적인 것에 있다고 보지 않았다. 통신의 한계점은 정보량에 기준한다는 새로운 패러다임을 제시한다.
60 | 
61 |     정보량은 초당 H이며 온전히 전달할 수 있는 채널 용량이 초당 C라고 가정하자.
62 |     H <= C 라면 정보에 비해 용량이 크므로 온전하게 전달 할 수 있다.
63 |     H > C 라면 잡음은 H-C미만으로 줄일 수 없다.
64 | 
65 | 섀넌은 위와 같은 정의를 내린다.
66 | 
67 | 이에 C를 키우기 위해 신호의 전력을 키우면 잡음도 증가한다를 수식적으로 증명한다.
68 | 
69 | 기존의 개념은 채널의 용량인 C를 키워 통신을 온전하게 만들자는 것이었다. 하지만 섀넌은 잡음을 더 줄일 수 없으니 H를 줄이자라는 길을 제시했다.
70 | 
71 | H는 정보의 양이며 정보량을 줄이는 방법은 엔트로피를 조정하면 된다. 이 개념에서 시작된 것이 압축이다.
72 | 
73 | ---
74 | 
75 | 참고자료
76 | 
77 | - [정보이론 1편](https://brunch.co.kr/@chris-song/68)
78 | - 컴퓨터과학이 여는 세계, 이광근, 인사이트
79 | - 성공과 실패를 결정하는 1%의 네트워크 원리, Tsutomu Tone, 이도희 역, BM성안당
80 | 


--------------------------------------------------------------------------------
/CS/non-blocking.md:
--------------------------------------------------------------------------------
 1 | # non-blocking
 2 | 
 3 | Non-blocking은 os와 알고리즘에 대한 것이다. 공유자원을 안전하게 동시 사용할 수 있도록 하는 방법론이다.
 4 | 
 5 | Non-blocking은 하나의 작업이 실패하거나 정지하더라도 다른 스레드에 영향을 주지 않도록 한다. 이를 위해 Non-blocking 알고리즘은 [lock-free](https://en.wikipedia.org/wiki/Non-blocking_algorithm#Lock-freedom) 특성과 [wait-free](https://en.wikipedia.org/wiki/Non-blocking_algorithm#Wait-freedom) 특성을 포함한다. lock-free는 wait-free를 포함하는 개념이다. 이로인해 non-blocking은 동시성(concurrency)을 갖는다.
 6 | 
 7 | > 동시성 : 프로그램을 실행할 때 단 하나의 실행 순서를 갖도록 하는 제약을 없애고 각 부프로그램이 다른 부프로그램과 병렬적으로 동시에 실행되는 것
 8 | 
 9 | lock-free 알고리즘이라는 것은 하나의 작업이 시작되어도, 시스템 전체의 진행이 보장되는 것이다.(A non-blocking algorithm is lock-free if there is guaranteed system-wide progress)<br/>
10 | wait-free 알고리즘은 각 스레드의 진행이 각각 보장되는 것(A non-blocking algorithm is wait-free if there is also guaranteed per-thread progress)이다. <br/>
11 | ![non-blocking i/o](/assets/images/non-blocking.png)
12 | blocking 모델은 요청이 동작 가능할때까지 스레드가 블록된다. 반면, non-blocking 모델은 요청이 동작 불가능하다는 것을 알려주어 블록상태 없이 계속해서 진행가능하다. 즉, 다른 스레드의 작업을 기다리지 않는다. 이를 통해 대기 상태 없이 공유 자원에 접근할 수 있다.
13 | 
14 | > Java의 멀티 스레드 어플리케이션에서 Synchronized를 시키는 것은 BlockingQueue Interface를 구현하는 것이라고 생각하면 된다. 당연히 non-blocking은 이와 반대다.
15 | 
16 | <br/>
17 | 
18 | ## Non-blocking I /O
19 | 
20 | Non-blocking I/O 는 I/O와 관계없이 프로세스가 계속해서 진행되는 것을 뜻한다. 기존 방식(blocking 혹은 synchronous한 I/O모델)에서는 I/O처리를 시작하면 작업이 끝날 때 까지 기다려야한다. 즉 프로그램이 block된다. 반면, Non-blocking I/O 모델에서는 입,출력을 외부에 맡겨 I/O의 진행 상황과 관계없이 프로그램이 진행된다.
21 | 
22 | <br/>
23 | 
24 | ## Asynchronous Programming과 Non-blocking I/O
25 | 
26 | 프로그램의 주 실행흐름을 멈추거나, 대기 상태 없이 즉시 다음 작업을 수행할 수 있도록 하는 것이 asynchronous 방식이다.
27 | 
28 | Ansynchronous programming은 언어 차원에서 지원하거나, 함수 전달을 통해 처리하는 방식을 통해 구현한다.<br/>언어차원에서 지원하는 방식은 future, promise와 같이 객체 형태의 결과를 돌려받거나 특정 문법을 이용하여 구현할 수 있다.<br/>함수 전달을 통해 처리하기 위해서는 함수를 값처럼 사용(일급 함수)를 지원하는 언어에서 Callback을 전달하여 결과를 처리할 수 있다. 
29 | 
30 | non-blocking 알고리즘과, non-blocking I/O 모델의 관점이 다른 것 처럼, Asnychronous programming은 Asynchronous I/O 와 다르다. 따라서 Asnychronous programming과 Non-blocking I/O는 서로 바라보는 관점이 다르다. Event-loop를 사용하여 동시성을 확보하였어도 I/O 작업이 blocking될 수 있기 때문이다.
31 | 
32 | <br/>
33 | 
34 | 만약 I/O 모델들의 조합을 알아보고 싶다면 다음을 참고하길 바란다. - [Asynchronous IO 개념 정리 - Uno's Blog](https://djkeh.github.io/articles/Boost-application-performance-using-asynchronous-IO-kor/)
35 | 
36 | ---
37 | 
38 | #### Refereces
39 | 
40 | - [Non-blocking Algorithms - jenkov.com](http://tutorials.jenkov.com/java-concurrency/non-blocking-algorithms.html)
41 | - [Blocking and Non-Blocking Algorithms - modernescpp](https://www.modernescpp.com/index.php/blocking-and-non-blocking)
42 | - [Non-Blocking Algorithms in Java - netjs.blogspot.com](https://netjs.blogspot.com/2016/06/non-blocking-algorithms-in-java.html)
43 | - [Non-blocking algorithm - wikipedia](https://en.wikipedia.org/wiki/Non-blocking_algorithm)
44 | - [멈추지 않고 기다리기(Non-blocking)와 비동기(Asynchronous) 그리고 동시성(Concurrency) - Peoplefund Tech](https://tech.peoplefund.co.kr/2017/08/02/non-blocking-asynchronous-concurrency.html)
45 | 


--------------------------------------------------------------------------------
/CS/non-linear-search.md:
--------------------------------------------------------------------------------
 1 | # 비선형(Non-Linear) 구조의 탐색
 2 | 
 3 | ## 선형 구조
 4 | 
 5 | 선형 구조를 간단히 설명하면, 말 그대로 진행하는 방향이 직선으로(일자로) 되어있는 구조이다. 알고리즘에서는 데이터가 연속적으로 연결되어있는 모양으로 구성이 된 것을 선형 구조라 한다. 선형 구조는 연결리스트, 스택, 큐, 덱 등이 있다.
 6 | 
 7 | > 선형 구조를 탐색하는 일반적인 방법론에는 순차검색과 이진검색이 있다.
 8 | 
 9 | <br/>
10 | 
11 | ## 비선형 구조
12 | 
13 | 비선형 구조는 선형이 아닌 구조이다. 어떤 원소를 탐색했을 때 다음에 탐색할 수 있는 원소가 여러 개 존재하는 구조가 비선형 구조이다. 비선형 구조는 트리나 그래프 형태로 표현할 수 있다.
14 | 
15 | > 트리는 순환(cycle)이 없는 그래프이다.
16 | 
17 | <br/>
18 | 
19 | ## 비선형 구조 탐색
20 | 
21 | 비선형 구조는 탐색해야 할 데이터가 순차적이지 않다. 따라서 단순한 반복만으로 탐색할 수 없다. 이 때문에 스택이나 큐와 같은 자료구조를 활용하여 탐색할 방법과 순서를 만들어 탐색한다. 일반적으로 깊이우선탐색(depth first search; DFS)과 너비우선탐색(breadth first search; BFS)을 이용한다. 만약 탐색 대상이 그래프일 경우 탐색이 완료되면 [신장트리(spanning tree)](http://59.23.150.58/30stair/spanning_tree/spanning_tree.php?pname=spanning_tree#spanning)가 만들어진다.
22 | 
23 | ![search](../assets/images/non-linear-search.gif)
24 | 
25 | > DFS와 BFS는 완전 탐색을 위한 방법이며, 가중치가 있는 그래프의 최단 거리를 찾기 위해서는 다익스트라와 플로이드-워셜 알고리즘이 주로 사용된다.
26 | 
27 | <br/>
28 | 
29 | ### 깊이우선탐색(DFS)
30 | 
31 | 시작점에서 더는 이동할 수 없는 지점까지 탐색한 뒤, 인접한 정점이 있었던 곳으로 돌아가 같은 방법으로 차례로 탐색하는 방법이다. 이때 시작점(부모노드)으로 되돌아오는 과정을 백트래킹이라고 한다.
32 | 
33 | 이러한 탐색 과정은 스택을 이용하는 것과 동일하기 때문에 스택을 사용하거나 재귀호출을 이용하여 구현한다.
34 | 
35 | ![dfs](../assets/images/non-linear-search-dfs.png)
36 | 
37 | 현 경로상의 노드만 기억하면 되기 때문에 저장공간이 비교적 적게 필요하다. 또한, 목표 노드가 깊을 경우 유리하다.
38 | 
39 | 반면, 해가 없는 너무 깊은 곳까지 탐색하게 되거나 목표에 이르는 경로가 많을 경우 비효율적이다. 또한, 찾은 경로가 최단 거리가 아닐 수 있다.
40 | 
41 | > 재귀호출을 하면 스택을 사용하는 것과 같은 효과를 낼 수 있다.
42 | 
43 | <br/>
44 | 
45 | ### 너비우선탐색(BFS)
46 | 
47 | 시작 정점을 방문한 후 시작정점에 인접한 모든 정점을 방문한 뒤, 해당 정점들과 인접한 정점을 탐색하는 방법이다. 이는 큐와 동일하다.
48 | 
49 | ![bfs](../assets/images/non-linear-search-bfs.png)
50 | 
51 | 하나의 레벨에서 보행 가능한 정점을 모두 찾아보기 때문에 목표 노드까지의 최단 길이가 결과로 나오는 것이 보장된다.
52 | 
53 | 반면, 경로가 길 경우(깊을 경우) 많은 기억 공간이 필요하다. 또한, 무한그래프의 경우 탐색이 불가능하다.
54 | > 무한 그래프는 정점이 무한한 그래프를 뜻한다. 
55 | > - DFS의 경우 하나의 정점의 결과값을 찾아 들어가기 때문에 무한한 정점 중에서 하나의 해를 구할 수 있으면 된다.
56 | > - 반면 BFS의 경우, 정점이 무한하다면 다음 수준으로 나아가는 것 자체가 불가능해진다.
57 | 
58 | ---
59 | 
60 | #### References
61 | 
62 | - [[알고리즘] 비선형구조의 탐색, 그래프의 구현 - https://12bme.tistory.com](https://12bme.tistory.com/123)
63 | - [깊이*우선*탐색 - 위키백과](https://ko.wikipedia.org/wiki/%EA%B9%8A%EC%9D%B4_%EC%9A%B0%EC%84%A0_%ED%83%90%EC%83%89)
64 | - [너비*우선*탐색 - 위키백과](https://ko.wikipedia.org/wiki/%EB%84%88%EB%B9%84_%EC%9A%B0%EC%84%A0_%ED%83%90%EC%83%89)
65 | - [[그래프] DFS와 BFS 구현하기 :: 마이구미 - https://mygumi.tistory.com](https://mygumi.tistory.com/102)
66 | - [[DFS][BFS] DFS 와 BFS - https://cru6548.tistory.com](https://cru6548.tistory.com/10)
67 | 


--------------------------------------------------------------------------------
/CS/soc.md:
--------------------------------------------------------------------------------
 1 | # 관심사 분리(Separation of Concerns; SoC)
 2 | 
 3 | 관심사 분리는 프로그램의 각 부분이 자신의 관심사만을 다루도록 분리되어야 한다는 것이다. 여기서 `관심사`란 프로그램 코드에 영향을 주는 일련의 정보를 의미한다.
 4 | 
 5 | > **예시**
 6 | > 자동차 창문을 여는 장치가 망가져 수리를 한다. 간단한 고장이기 때문에 금방 수리를 했다.
 7 | > 하지만 창문은 잘 고쳤는데 갑자기 시동이 걸리지 않는다. 원인은 자동차를 자동차를 제어하는 배선이 너무 복잡해 창문을 제어하는 배선을 만지면 차량의 시동을 거는 배선에도 영향을 주기 때문이었다.
 8 | > 만약 창문을 제어하는 배선과 시동을 거는 배선이 잘 분리되어 있다면 이런 일은 발생하지 않았을 것이다.
 9 | 
10 | 만약 위의 예시를 프로그램화 했다면 창문을 제어하는 기능과 시동을 거는 기능을 분리하는 것으로 생각해볼 수 있다. 이처럼 각 기능들이 서로 얽히지 않고 각각의 역할만 하도록 하는 것을 관심사 분리라고 한다. 각각의 모듈은 각자의 기능만을 해결해야 한다.
11 | 
12 | 관심사 분리는 추상화의 한 형태이다. 때문에 관심사 분리를 위해서 캡슐화가 잘 되어야 한다. 기능의 구현은 내부적으로 숨겨놓고 해당 모듈을 실행시켰을 때 정확한 기능이 동작하도록 보장되어야 한다. 인터페이스 뒤에 모듈의 구현 세부사항을 숨기면 다른 부분의 세부사항을 알 필요 없이 해당 코드를 개선하거나 수정할 수 있다. 이렇게 되면 다른 기능에 영향을 주지 않고 유지 보수가 가능하다.
13 | 
14 | 계층화(layered) 된 설계는 관심사 분리의 좋은 예시이다. 예를들어 MVC패턴의 각 계층(layer)은 각각의 관심사만을 수행하도록 구성된다. 이외에도 객체 지향 언어에서는 관심사를 객체로 분리할 수 있으며 절차 지향 언어에서는 관심사를 메소드 혹은 프로시저로 분리할 수 있다.
15 | 
16 | 웹 프로그램을 개발할 때 JSP 파일 안에 SQL을 작성하지 않는다. 결과를 계산하는 모듈에서 HTML 파일을 생성하지 않는다. 또한 비즈니스 규칙은 데이터베이스 스키마와 독립적으로 이루어져야한다. 만약 그렇게 작성한다면 하나의 기능에 대한 수정때문에 모든 기능이 중단될 수 있다. 이는 관심사 분리를 해야하는 이유이다.
17 | 
18 | ---
19 | 
20 | #### References
21 | 
22 | - [The Single Responsibility Principle](https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html)
23 | 


--------------------------------------------------------------------------------
/CS/페이징과 세그먼테이션.md:
--------------------------------------------------------------------------------
 1 | # 페이징 기법과 세그먼트 기법
 2 | 
 3 | ## 가상기억장치
 4 | 
 5 | 가상기억장치는 **주기억장치의 용량이 부족할 때 하드디스크의 일부 공간을 마치 주기억장치처럼 사용하는 기억장치**를 말한다.  
 6 | 가상기억장치에 프로그램을 저장할 때는 불필요한 메모리 낭비를 줄이기 위해 프로그램을 여러 개의 블록 단위로 나눠 보관한다. 각각의 블록은 **mapping** 과정을 통해 주기억장치에 적재된다.   
 7 | 주기억장치와 가상기억장치 간 프로세스를 무슨 단위로 load하고 store할지 정하는 방법에는 페이징 기법과 세그먼테이션 기법이 있다.
 8 | 
 9 | <br/>
10 | 
11 | ## 페이징 기법  
12 | 
13 | ### Page와 Page frame, Swapping  
14 | 
15 | ![Page Pageframe](../assets/images/page_pageframe.png)    
16 | 
17 | 우선 페이징 기법은 위 그림과 같이 가상기억장치의 블록을 **고정 크기**로 나눈다. 이 블록을 **Page** 라고 부르며, 프로그램 실행시 요구되는 블록만 주기억장치에 적재된다. 주기억장치의 메모리 역시 Page와 같은 단위의 블록으로 나뉘는데, 이 명칭을 **Page frame** 이라고 한다.   
18 | 주기억장치에 모든 작업이 상주하지 않기 때문에 프로그램 실행 중 필요한 부분만 교체할 수 있다. 이를 **Swapping** 이라고 한다.   
19 | 
20 | <br/>
21 | 
22 | ### Page mapping - Page fault
23 | 
24 | Page mapping 과정을 위해서는 주기억장치에 **Page table** 이 생성된다.(때문에 Page의 크기가 작을수록 더 많은 주기억장치의 메모리가 낭비된다.) Page table은 Page의 번호, Page Frame의 시작주소 등이 저장되어있다.  
25 | Page frame에 적재되는 Page가 교체되거나 Page fault가 발생할 때마다 Page Table은 갱신된다.    
26 | 
27 | **Page fault** 는 프로그램에서 필요로 하는 Page가 주기억장치에 있지 않는 경우에 발생하는 현상이다. Page fault가 발생하면 Page를 찾아 mapping하고 Page Table이 갱신되는 일이 발생된다. 이러한 현상을 줄이기 위해서 Page frame의 크기를 늘릴 수 있다.
28 | 
29 | <br/> 
30 | 
31 | ### Thrashing
32 | 
33 | 너무 많은 Page fault 현상으로 페이지 교체 시간이 프로세스 수행 시간보다 많은 경우를 말한다. Thrashing이 발생하면 CPU 이용률이 급격히 감소하므로 이를 방지하기 위해 다중 프로그래밍의 정도를 낮추거나 Page frame의 크기를 늘려야 한다.  
34 | 
35 | <br/>
36 | 
37 | ### 내부단편화
38 | 
39 | 프로그램의 크기가 30k이고, 각 page의 고정 크기가 4k라고 한다면 마지막 page의 실질적 크기는 2k가 될 것이다. 따라서 마지막 page가 주기억장치에 적재될 때 2k만큼의 **내부단편화**가 발생된다. 즉 필요한 공간보다 더 큰 메모리가 할당되어 불필요하게 메모리가 낭비되는 현상을 내부단편화라고 한다. 이를 해결하기 위해 page를 작게 만들 수도 있지만 위에서 언급했듯이 page를 무조건 작게 만드는 것이 능사는 아니다.   
40 | 
41 | <br/>
42 | 
43 | ## 세그먼테이션 기법
44 | 
45 | 세그먼테이션 기법은 페이징 기법과 달리 프로그램을 기능별로 분할하는 것을 말한다. 또한 주기억장치는 구분하지 않고, 전체를 비연속적으로 할당받는다. 따라서, 페이징 기법이 프로그램을 물리적으로 분할한 개념이라면 세그먼테이션은 논리적으로 분할한 개념이다.    
46 | 
47 | ![segmentation](../assets/images/segmentation.png)  
48 | 
49 | ### Seg fault, 외부 단편화
50 | 
51 | 세그먼테이션 기법에서는 세그먼트 길이에 맞는 주기억장치의 영역을 할당받지 못한 경우 해당 프로그램이 다른 프로그램의 영역을 침범하는 **Seg fault**가 발생할 수 있다.    
52 | 
53 | 또한 고질적인 문제로 **외부단편화**가 발생할 수 있다. 위 그림에서 `B-1`의 크기가 6K,남은 공간이 3K라고 가정해보자. `B-1`의 프로세스가 끝나고 메모리를 해제하면 주기억장치에는 `A-1 / 빈공간(6k) / B-3 / 빈공간(3k)`가 있을 것이다. 여기에 7k 크기의 프로세스가 들어오려고 한다면, 총 공간은 9k지만 각 공간이 7k보다 작기 때문에 적재될 수 없다. 이런 현상을 외부 단편화라고 한다. 이를 해결하기 위해 `통합` 또는 `압축`을 할 수 있다.   
54 |   
55 | 다음의 그림과 같이, 통합은 빈 공간의 주소가 인접한 경우 하나로 합치는 방법이고 압축은 프로세스의 재배치를 통해 모든 빈 공간을 하나로 합치는 방법이다. 
56 | 
57 | ![coalescing](/assets/images/coalescing.png)  
58 | ![compaction](/assets/images/compaction.png)
59 |    
60 | 
61 | 
62 | #### Reference
63 | [특수기억장치 및 기억장치의 분류](http://junhojohn.blogspot.com/2018/11/blog-post_12.html)


--------------------------------------------------------------------------------
/Deprecated/AMD와 CommonJS.md:
--------------------------------------------------------------------------------
  1 | # AMD와 CommonJS
  2 | 
  3 | ## 배경
  4 | 
  5 | 자바스크립트(ES5 기준)는 파이썬, 루비, 다른 스크립트 언어 계열과 차이점이 존재한다.
  6 | 
  7 | 바로 **모듈 사용의 표준이 존재하지 않는다는 것**이다.
  8 | 
  9 | Node.js를 사용하고 있는 개발자들은 `module.exports`를 통해 모듈을 정의하고 `require()` 함수를 통해 정의한 모듈을 불러와 사용하고 있다.
 10 | 
 11 | 이러한 방식을 **CommonJS**라고 한다.
 12 | 
 13 | 프론트엔드에서는 위와 같은 모듈 제공 방식이 없었다.
 14 | 
 15 | 이에 따라 `window`객체를 이용하여 모듈의 리소스를 전달하는 방식을 이용했었다.
 16 | 
 17 | ```js
 18 | //math.js
 19 | var sum = function() {
 20 |     var total = 0;
 21 |     for (var idx in arguments) {
 22 |         total += arguments[idx];
 23 |     }
 24 |     return total;
 25 | };
 26 | 
 27 | window.Math = {
 28 |     sum: sum
 29 | };
 30 | ```
 31 | 
 32 | ```js
 33 | //main.js
 34 | if (typeof Math !== 'undefined') {
 35 |     if (typeof Math.sum === 'function') {
 36 |         console.log(Math.sum(1, 2));
 37 |     } else {
 38 |         throw new Error('Math.sum function is not defined.');
 39 |     }
 40 | } else {
 41 |     throw new Error('A module `Math` is undefined.');
 42 | }
 43 | ```
 44 | 
 45 | 위 소스를 보면 **전역 오브젝트인 `window` 객체를 통해 다른 자바스크립트 파일에 리소스를 전달** 하고 있다.
 46 | 
 47 | 하지만 이것도 사용하는 HTML에서 불러오는 모듈 파일을 먼저 로드해야한다.
 48 | 
 49 | 즉, **대상 모듈이 존재할수도, 존재하지 않을 수도 있는 상태**가 된다.
 50 | 
 51 | 이후 점차 프로젝트 규모가 커지게 되면서 프론트엔드에서 좀 더 효율적인 모듈화를 제공하기 위헤 `AMD`와 `CommonJS` 방식이 생겨나게 됐다.
 52 | 
 53 | <br/>
 54 | 
 55 | ## AMD(Asynchronous Module Definition)
 56 | 
 57 | AMD에서는 `define`을 사용한다.
 58 | 
 59 | ```js
 60 | //math.js
 61 | define([], function() {
 62 |     return {
 63 |       sum: function() {
 64 |           var total = 0;
 65 |           for (var idx in arguments) {
 66 |               total += arguments[idx];
 67 |           }
 68 |           return total;
 69 |       }
 70 |     };
 71 | });
 72 | ```
 73 | 
 74 | ```js
 75 | //main.js
 76 | requirejs.config({
 77 |     baseUrl: './'
 78 | });
 79 | 
 80 | require(['math'], function(Math) {
 81 |   console.log(Math.sum(1, 2));
 82 | });
 83 | ```
 84 | 
 85 | 원래 AMD의 규칙을 따르는 도구를 사용해 모듈을 정의하고 불러와야하지만 위의 코드에선 ReuireJS를 사용했다.
 86 | 
 87 | <br/>
 88 | 
 89 | ## CommonJS
 90 | 
 91 | CommonJS 방식은 위에서도 말했듯이 **Node.js에서 사용하고 있는 모듈 방식**이다. 이것이 CommonJS 방식의 제공이 중요한 이유다.
 92 | 
 93 | ```js
 94 | module.exports = {
 95 |     sum: function() {
 96 |         var total = 0;
 97 |         for (var idx in arguments) {
 98 |             total += arguments[idx];
 99 |         }
100 |         return total;
101 |     }
102 | };
103 | ```
104 | 
105 | ```js
106 | var math = require('./math');
107 | 
108 | console.log(math.sum(1, 2));
109 | ```
110 | 
111 | ### CommonJS 방식으로 제공되어야 하는 경우
112 | 
113 | ---
114 | 
115 | * 프론트엔드 라이브러리일지라도 Node.js 코드를 통해 유닛 테스팅을 하는 경우
116 | 
117 | * `moment.js`, `underscore.js`처럼 Node.js에서도 사용 가능해야하는 라이브러리 일 경우 
118 | 
119 | <br/>
120 | 
121 | ## 모듈 제공의 방향과 ES6
122 | 
123 | 이전 Module 제공 방식의 추세가  AMD vs CommonJS였다면, CommonJS와 ES6 타입으로 축약되는 것으로 보인다. 
124 | 
125 | 즉, **AMD 방식은 사양되는 분위기**다.
126 | 
127 | 하지만 여전히 일부 라이브러리가 AMD방식을 사용하고 있어 지금도 번들링은 UMD로 하고 있다.
128 | 
129 | 위의 내용까지는 ES5기준으로 본 모듈 방식의 정의고 ES6기준으로 보면 또 다른 모듈 방식이 존재한다.
130 | 
131 | **ES6 모듈은 import를 제공하여 모듈을 불러오는 방식**이다.
132 | 
133 | require.js와 import를 사용하여 모듈을 불러올 때 각각의 차이 중 하나는 **Tree-Shaking**을 할 때 알 수 있다.
134 | 
135 | **`import`를 사용한 방식은 라이브러리의 특정 모듈만을 가져와 번들링할 수 있지만, `require` 방식으로 가져온 라이브러리는 모듈 전체를 번들링**해야한다.
136 | 
137 | 즉, **`require` 방식으로 가져온 모듈에 대해서는 Tree-shaking을 진행할 수 없다.**
138 | 
139 | <br/>
140 | 
141 | ---
142 | 
143 | #### Reference
144 | 
145 | - [자바스크립트 모듈 제공을 위한 AMD, CommonJS 그리고 RequireJS 소개](https://blog.pigno.se/post/157992405313/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8-%EB%AA%A8%EB%93%88-%EC%A0%9C%EA%B3%B5%EC%9D%84-%EC%9C%84%ED%95%9C-amd-commonjs-%EA%B7%B8%EB%A6%AC%EA%B3%A0-requirejs-%EC%86%8C%EA%B0%9C)
146 | - [JavaScript 표준을 위한 움직임: CommonJS와 AMD](https://d2.naver.com/helloworld/12864)


--------------------------------------------------------------------------------
/Deprecated/EventLoop.md:
--------------------------------------------------------------------------------
 1 | # 자바스크립트의 이벤트루프와 콜백함수
 2 | 
 3 | ## 이벤트루프와 싱글 쓰레드
 4 | 
 5 | 자바스크립트와 콜백은 뗄레야 뗄 수 없는 관계라고 생각한다. 흔히들 자바스크립트는 싱글쓰레드 기반이라고 얘기합니다. 그게 바로 이벤트루프가 싱글 쓰레드기 때문에 하는 얘기다. 그럼 이 이벤트 루프는 무엇일까?
 6 | 
 7 | ## 자료구조
 8 | 
 9 | 스택은 밑이 비어있는 컵 모양에 넣고 빼는 것이며 큐는 양쪽이 뚫려있는 튜브라고 말한다. 스택은 LIFO이며 큐는 FIFO다.
10 | 
11 | 이 자료구조는 자바스크립트 엔진에서 사용됩니다. 바로 호출 '스택'과 태스크 '큐'입니다.
12 | 
13 | 호출 스택은 어느 언어에서도 존재한다. 쉽게 생각하자면 [main(), a(), b()] 구조로 호출되면 b -> a -> main 순으로 빠져 나간다. 자 그러면 이제 `setTimeout()`을 생각해보자.
14 | 
15 | ```js
16 | function foo() {
17 |   console.log('b');
18 | }
19 | console.log('a');
20 | setTimeout(foo, 0);
21 | console.log('c');
22 | ```
23 | 
24 | 이러면 출력결과는 당연히 a -> c -> b가 된다.. 의사코드로 소스를 분석해봅시다.
25 | 
26 | 1. a를 출력해라
27 | 2. 0초 뒤에 foo를 실행해라
28 | 3. c를 출력해라
29 | 
30 | 그렇다면 a -> b -> c가 되어야 하는것 아닐까 할 수 있다. 이는 호출스택에서는 당연히 맞지만 자바스크립트에서는 그렇지 않다. 자바스크립트는 호출 스택만 사용하지 않기 때문이다. 자바스크립트는 호출스택, 백그라운드, 태스크 큐(es6+부터는 큐 관리방식이 변화되어 태스크 큐 이외도 존재)라는 개념이 존재한다.
31 | [자바스크립트 비동기 작업 3가지](./EventLoop_Advanced.md)
32 | 
33 | ![eventLoop](/assets/images/EventLoop.png)
34 | 
35 | 이런 구조입니다. 자 이제 코드대로 생각을 해보자.
36 | 
37 | 1. main() 스택에 들어감
38 | 2. log("a") 도 스택에 들어간 뒤 실행
39 | 3. setTimeout()이 스택에 들어간 뒤 실행 - 백그라운드에서 0초뒤에 foo를 "실행"시키라고 명령
40 | 4. 0초가 지나 "태스크큐"에 foo()들어감
41 | 5. log("c") 가 스택에 들어간 뒤 실행
42 | 6. main() 종료
43 | 7. 태스크 큐에 있던 foo()를 호출스택에 밀어넣음 (이벤트 루프가 전역 컨텍스트의 main이 종료되면 큐 실행)
44 | 8. foo()가 호출스택에 들어간 뒤 실행
45 | 
46 | 이래서 결과가 위와 같았다.
47 | 
48 | ## 콜백함수
49 | 
50 | 이런 자바스크립트의 싱글 쓰레드 구조에서 비동기성의 이벤트 기반 실행이나 ajax요청이 필요하다면, 콜백 함수를 이용해 백그라운드로 보내고 큐를 통해 호출 스택으로 보내 해결하게 된다.
51 | 
52 | 자바스크립트에서는 쓰레드를 통해 병렬처리가 안되기 때문에 콜백함수의 사용은 뗄 수가 없게 되는 것이다.
53 | 
54 | ## 큐와 콜백
55 | 
56 | 이러한 이벤트 루프의 가장 중요한 점은 바로 위 과정의 3번과 4번 그리고 7번이다. 흔히 setTimeout(foo, 3)이라는 함수를 말할 때 foo 함수를 3초 뒤에 실행시켜라 라고 생각한다. 그러나 4번에 보듯 foo는 일정시간 뒤에 실행되는게 아니라 큐에 들어가게 된다.
57 | 
58 | 3번에 `백그라운드에서 0초뒤에 foo를 "실행"시키라고 명령`이라고는 적었지만 정확히 말하자면 `foo를 "큐"에 집어넣어라` 가 맞는 것이다. 큐에 아무것도 없다면 3초뒤에 바로 실행이 되겠지만 만일 다른 콜백으로 인해 다른 작업들이 존재한다면 어떻게 될까??
59 | 
60 | 맞다. 3초가 넘어가서 실행되게 됩니다. setTimeout()이라는 함수는 n초 뒤에 콜백을 단순히 큐에 집어넣는게 끝이다. 이 큐에 들어간 콜백은 이벤트 루프가 스택으로 밀어넣어 실행된다다. 코드를 간단히 보자면 아래와 같다.
61 | 
62 | ```js
63 | var eventLoop = [];
64 | var event;
65 | 
66 | while (true) {
67 |   // 틱!
68 |   if (eventLoop.length > 0) {
69 |     event = eventLoop.shift();
70 |   }
71 | 
72 |   try {
73 |     event(); // 호출스택으로 밀어넣는다
74 |   } catch (err) {
75 |     //...
76 |   }
77 | }
78 | ```
79 | 
80 | 이 큐에 이미 대기번호가 100개가 있다면 foo는 101번째 대기표를 받게 될 것이다. 따라서 setTimeout()은 지정한 시간동안은 실행되지 않는 것은 보장할 수 있지만 지정한 시간에 실행되는것은 보장할 수 없다!
81 | 
82 | ## 현재 이벤트 루프
83 | 
84 | es6+부터는 잡큐와 같은 새로운 개념이 등장하고 promise를 이용해 콜백을 처리하게 되는데 이는 나중에 더 다루도록 하겠습니다.
85 | [자바스크립트 비동기 작업 3가지](./EventLoop_Advanced.md)
86 | 


--------------------------------------------------------------------------------
/Deprecated/Javascript_BuildTool.md:
--------------------------------------------------------------------------------
 1 | # Webpack과 Gulp 그리고 Grunt
 2 | 
 3 | 현재 Build Tool의 대세는 당연코 Webpack이다. 그런데 이 이전에는 Gulp와 Grunt가 있었다. 나는 자바스크립트 빌드의 개념을 배울 때 이미 웹팩이 대중화되는 시기였다. 그래서 그냥 웹팩을 사용했다. 그런데 모든 새로운 기술에는 등장이유가 있으며 장점과 단점이 존재한다. 웹팩이 다른 기술들과는 어떤 차이점을 가지는지 간단하게 알아보자.
 4 | 
 5 | ## Webpack과 Gulp&Grunt는 태생부터 다르다
 6 | 
 7 | ### Gulp와 Grunt
 8 | 
 9 | ---
10 | 
11 | webpack과 gulp, grunt는 사실 아예 다르다. Gulp와 Grunt(이하 걸프로 통일하겠음)는 Task Runner라고 한다.
12 | 용어로 얘기하면 되게 생소해 보이지만 별건 없다. 간단한 Task를 실행해주는 것이다. uglify나 압축등의 반복 가능한 간단한 작업을 자동화해주는 툴이다.
13 | 
14 | ### 서로의 차이점
15 | 
16 | ---
17 | 
18 | gulp와 grunt의 하는일은 같지만 만들어내는 방식이 다르다. grunt는 package.json처럼 json형식으로 설정을 선언하여 사용한다. 이와 다르게 gulp는 nodeJS의 스트림 기능을 이용하여 자바스크립트 코드를 사용한다. 이건 현재 유행하는 기술도 아니고 크게 중요한 점도 아니니 넘어가도록 하자.
19 | 
20 | ## Webpack
21 | 
22 | 이전 툴들이 Task Runner인 것과 다르게 웹팩은 이름부터 다르다. `Module Bundler` 혹은 `Package Bundler` 라고 불린다. 모듈 개념은 이미 한 번 정리 했었다. [Module](./Module.md)
23 | 
24 | ### 모듈번들러
25 | 
26 | ---
27 | 
28 | 모듈 번들러가 뭐냐면 이 각각의 모듈들의 의존성을 파악하여 번들(묶는다)해주는 것이다. 모듈과 의존성이라는 단어가 낯설다. 이 단어들에 대해서 다시 생각해보자.
29 | 
30 | ### 모듈과 의존성
31 | 
32 | ---
33 | 
34 | 자바스크립트는 큰 소스를 나눠 편하게 개발하고 유지보수하기 위해 모듈이라는 추상적인 개념을 사용한다. 마치 클래스와 비슷하다 이렇게 모듈 방식으로 코딩을하고 거기에 모듈별로 파일까지 나누어 개발하면 참 좋다. 모듈과 파일이 분기된 개념은 보통은 노드JS에서 많이 사용한다.
35 | 
36 | 모듈화 된 각각의 파일들은 서로의 의존성을 가진다. 의존성이란 쉽게 말해 `import * from './index'` 이 구문이다. 현재 파일에서 다른 파일을 이용하게되면 서로 의존성이 생긴다.
37 | 
38 | 그런데 브라우저 상에서는 이러한 의존성을 표현하기가 어렵다. 특히 HTTP/1.1을 사용해야 하는 환경이라면 더욱 힘들다. HTTP/2.0의 경우 한 번의 요청에 여러 파일을 받아올 수 있지만 1.1의 경우는 의존성을 통해 여러 파일이 필요하게 된다면 너무 많은 네트워크 자원을 소모하게 된다.
39 | 
40 | 그러면 많은 의존성으로 엮인 JS파일들을 그냥 하나의 JS파일로 압축해서 만들면 어떨까?? 요청 한 번에 그 압축파일 하나만 주면 땡! 하게 말이다. 그게 웹팩이다. 꼭 하나는 아니다. 라이브러리 / 핵심 소스를 나누어 파일을 두개로 분기할 수도 있다. 요점은 다양한 파일들을 번들(bundle)해서 네트워크 비용을 최소화하여 파일을 번들한다! 라는 것이다.
41 | 
42 | Gulp나 Grunt처럼 필요한 자동화 기능까지 더해 빌드 해주는 것이 바로 모듈 번들러다.
43 | 
44 | ### 더 나아가
45 | 
46 | ---
47 | 
48 | 웹팩은 위에서 말한 자바스크립트의 의존성을 파악하여 번들하는 것만이 아니다. 모든 리소스(javascript, css, image, font, 심지어 typescript, coffeescript, less, sass 등)에 대한 dependancy graph를 생성하여 빌드 시켜준다. 요즘처럼 SPA를 구현하게 되면 이러한 의존성은 꼬리에 꼬리를 물고 Graph(Tree) 형태로 만들어지게 되는데 이걸 번들링하여 하나의 js 파일로 딱 만들어주는게 모듈 번들러의 역할이다.
49 | 
50 | ## 결론
51 | 
52 | 두 종류의 빌드 툴 모두 리소스들을 압축한다는 공통점이 있다.
53 | 
54 | Gulp나 Grunt는 단순 자동화 작업으로 파일을 압축하는 작업을 많이 하게 된다. 그러나 웹팩의 경우 자바스크립트의 각 모듈 혹은 파일, 심지어는 다양한 리소스들까지 의존성을 파악하여 묶어주기 때문에 엄청나게 큰 차이점을 보인다.
55 | 
56 | 따라서 현재 코드가 모듈화 된 코드가 아니거나, 다양한 의존성을 다루어야 하는 작업이 아니라면 Gulp나 Grunt도 충분히 좋은 빌드 툴이 될 수 있다. 그러나 꽤 준수한 프로젝트 규모를 가지거나, 자바스크립트를 모듈화하여 코딩하거나, 무거워질 수 밖에 없는 프레임워크를 사용하는 프로젝트 등에는 웹팩이 훨씬 더 좋은 툴이 될 것이다.
57 | 


--------------------------------------------------------------------------------
/Deprecated/Module.md:
--------------------------------------------------------------------------------
  1 | # javascript의 module
  2 | 
  3 | Java나 Python과 같은 OOP 언어들에서는 Class라는 이름으로 객체지향 프로그래밍을 구현해왔다. OOP의 보통 특징으로는 널리 알려져있듯 encapsulation, inheritance, polymorphism이 있다. 그 중 자바스크립트의 scope를 공부하고 있었는데 encapsulation과 관련이 있었으며, 자연스레 class와 비슷한 기능을 하는 자바스크립트의 module을 공부해봤다.
  4 | 
  5 | javascript에서는 이 scope를 기준으로 캡슐화를 한다. 그래서 자연스레 이 scope를 이용하여 외부로부터 보호하려는 노력이 있어왔다. ES5에서는 함수가 scope의 기준이기 때문에 당연히도 함수의 scope를 이용해 encapsulation을 시도했다. 또한 자신의 스코프의 참조를 가진다는 클로저를 이용해 내부 속성들을 사용할 수 있게 했다.
  6 | 
  7 | ## ES 5의 모듈화
  8 | 
  9 | 크게 세가지가 있었다. IIFE(즉시실행함수표현식), 노출식 모듈 패턴, AMD다. 여기서 AMD는 크게 중요하지 않다고 생각되어 define을 사용한다고만 하고 넘어가겠다.
 10 | 
 11 | ### IIFE
 12 | 
 13 | ---
 14 | 
 15 | 함수를 즉시 호출시켜 스코프를 오염시키지 않는 방식이다.
 16 | 
 17 | ```js
 18 | function moduleFunction() {
 19 | 
 20 |   var a = 3;
 21 | 
 22 |   function helloWorld(){
 23 |     console.log('Hello');
 24 |   }
 25 | 
 26 |   return {
 27 |     a : a,
 28 |     sayHello: helloWorld
 29 |   }
 30 | }()
 31 | 
 32 | moduleFunction.sayHello();
 33 | doSomething(moduleFunction.a);
 34 | ```
 35 | 
 36 | 함수를 바로 실행시킨 뒤 object를 반환하여 전역 네임을 한번만 사용하여 스코프를 오염시키지 않는다. 또한 외부에서 내부 코드로의 접근을 차단하여 보호한다. 모듈의 개념을 잘 이행하고 있다. 다만 의존성관리가 되지 않는다. 코드를 재 작성하지 않으면 다른 파일에서 재사용이 불가능하다.
 37 | 
 38 | ### 노출식 모듈패턴
 39 | 
 40 | ---
 41 | 
 42 | IIFE와 크게 다르는 않다. 반환값을 변수에 담으면 되는데 singleton 의 패턴이다.
 43 | 
 44 | ```js
 45 | var singleton = (function moduleFunction() {
 46 |   var a = 3;
 47 | 
 48 |   function helloWorld() {
 49 |     console.log('Hello');
 50 |   }
 51 | 
 52 |   return {
 53 |     a: a,
 54 |     sayHello: helloWorld
 55 |   };
 56 | })();
 57 | 
 58 | singleton.sayHello();
 59 | doSomething(singleton.a);
 60 | ```
 61 | 
 62 | 비슷하다. 이 역시 문제는 의존성관리가 안된다.
 63 | 
 64 | ## Node JS의 모듈화
 65 | 
 66 | 의존성 관리 문제 때문에 ES5에서는 AMD, UMD, CommonJS 와 같은 모듈 포맷을 사용했는데 여기서는 가장 흔히 알려진 CommonJS방식에 대해 알아보자
 67 | 
 68 | ```js
 69 | var dep1 = require('./dep1');
 70 | var dep2 = require('./dep2');
 71 | 
 72 | module.exports = function() {
 73 |   // ...
 74 | };
 75 | ```
 76 | 
 77 | 와 같은 구조다. 흔히 구글링한 코드에서 찾아볼 수 있는 `require`, `module.exports` 구조다. 외부의 dep1.js를 `module.exports`로 내보내고 `require()`로 불러와 사용하는 방식이다. 사실 내부적으로는 IIFE와 크게 다르지 않다. 내보낼 module을 파라미터로하여 IIFE를 실행시키고 반환하는 방식이다.
 78 | 하지만 파일 외부에서 작성하고 불러온다는 점에서 많이 나아진 방식이다.
 79 | 
 80 | ## ES 6 모듈
 81 | 
 82 | ES 6에서는 모듈을 사용하기 위한 내장 문법을 지원한다. 바로 `export`다.
 83 | 
 84 | ```js
 85 | // some.js
 86 | export function helloWorld() {
 87 |   console.log('Hello');
 88 | }
 89 | 
 90 | function somePrivateFunction() {
 91 |   // ...
 92 | }
 93 | 
 94 | // ===========
 95 | // ===========
 96 | 
 97 | // something.js
 98 | import { helloWorld as hello } from './some';
 99 | // import * from './some' 도 가능합니다.
100 | 
101 | hello();
102 | ```
103 | 
104 | 이렇게 하면 파일을 분리하고 그 파일에서 필요한 부분만 반환하여 사용할 수 있게 된다. 또한 재사용성이 극대화되어 의존성 관리도 가능하게 된다.
105 | 
106 | 현재 예제 코드에서는 함수만 반환했지만 당연히 object도 가능하다.
107 | 
108 | 또한 단일 값을 반환할 경우 default 형식을 지원한다. 이 경우 {} 를 사용하지 않아도 된다.
109 | 
110 | ```js
111 | // lib.js
112 | 
113 | // Export default function
114 | export default function sayHello(){
115 |   console.log('Hello');
116 | }
117 | 
118 | 
119 | // Export non-default function
120 | function sayGoodbye(){
121 |   console.log('Goodbye');
122 | }
123 | 
124 | // Export simple value
125 | const apiUrl = '...';
126 | 
127 | returnObject = {
128 |     goodbye : sayGoodbye,
129 |     apiUrl : apiUrl
130 | }
131 | export returnObject;
132 | 
133 | // Export object
134 | export const settings = {
135 |   debug: true
136 | }
137 | 
138 | // app.js
139 | import sayHello, { returnObject, settings } from './lib';
140 | 
141 | sayHello();
142 | returnObject.sayGoodBye();
143 | ```
144 | 
145 | 하지만 현재 이러한 모듈 포맷은 모든 브라우저에서 지원하지 않는다. 따라서 Babel과 같은 변환기를 통해 ES5에서 사용하던 방식인 AMD나 CommonJS 형식으로 코드를 변환한 뒤 사용한다.
146 | 


--------------------------------------------------------------------------------
/Deprecated/Promise1.md:
--------------------------------------------------------------------------------
  1 | # Promise1
  2 | 
  3 | ## 콜백을 구하라
  4 | 
  5 | 프로미스를 몇번 사용은 해봤다. 그러나 사실 이게 왜 대단한지 크게 알 수 가 없었다. 체이닝이 되서 추적이 쉽다는것? async / wait 을 이용해서 비동기/동기를 이동할 수 있다는 것? 정도만 알고 있었다.
  6 | 
  7 | 하지만 이번에 공부하면서 이게 왜 등장했으며 어떤 장점이 있는지 조금은 알게 되었다.
  8 | 
  9 | ## 제어의 역전
 10 | 
 11 | 콜백 지옥의 문제점은 제어의 역전이다. 믿음직하지 못한 어떤 비동기 프로그램에게 우리 프로그램의 호출 제어권을 넘겨주어 어떤 일이 발생할 수 있다는 것이다.
 12 | 
 13 | 이전 시리즈의 예를 다시 들어보자.[Callback](./Callback.md)
 14 | 
 15 | ```js
 16 | solutionUtil.trackPurchase(purchaseData, function CBF() {
 17 |   // 결제데이터를 넘긴 뒤
 18 |   // 비동기적인 처리가 완료되면 콜백실행
 19 |   assignCredit(); // 결제
 20 |   goThanksPage(); // 페이지 이동
 21 | });
 22 | ```
 23 | 
 24 | 저 유틸의 trackPurchase 라는 함수는
 25 | 
 26 | - purchaseData 와 콜백함수 두가지 인자를 받는다.
 27 | - 우리는 알 수 없는 어떤 로직 진행 후 완료가되면 콜백함수를 실행한다.
 28 | 
 29 | 이 과정의 문제점은 콜백의 실행 제어권이 저 함수에게 넘어간다는 점이다. 저 함수안에서 어떤 일이 잘못되어 콜백함수가 5 번 실행될 수 있다는 게 가장 큰 문제였다.
 30 | 
 31 | ## 제어의 재역전
 32 | 
 33 | 자 이제 저 제어권을 돌려받자. 콜백을 저 함수가 아니라 우리가 실행할 수 있게 만들자는 개념이 promise 다.
 34 | 먼저 예시를 들어보자.
 35 | 
 36 | 1. 어떤 작업을 하려고 foo()라는 함수를 부른다.
 37 | 2. foo()의 내용은 관심이 없지만 foo()가 끝나길 기다린다.
 38 | 3. foo()가 끝나면 어떤 작업을 실행한다.
 39 | 
 40 | 콜백 베이스의 코드라면 foo()를 실행할 때 콜백을 넘겨준다.
 41 | 
 42 | ```js
 43 | foo(someData, bar(), barErr());
 44 | ```
 45 | 
 46 | 이렇게 하면 foo 가 자신이 끝나면 bar()를 **백그라운드**에서 실행한다. 하지만 자바스크립트에는 이벤트 방식도 존재한다.
 47 | 
 48 | ```js
 49 | function foo(x) {
 50 |   // 어떤 일을 실행하고 이벤트를 반환
 51 |   return listner;
 52 | }
 53 | 
 54 | var evt = foo(42);
 55 | 
 56 | evt.on('completion', bar());
 57 | evt.on('failure', barErr());
 58 | ```
 59 | 
 60 | 이거다 바로. 이게 사실 프로미스가 실행되는 방식이다.
 61 | 위의 코드를 잘 생각해보자. foo 가 비동기적으로 실행되고 그 결과를 받아 evt 에 저장한다.foo(42)가 완료되어 evt 에 할당되면 그걸 우리가 읽고 다음 단계를 실행한다.
 62 | 
 63 | 콜백 패턴을 뒤집었다. 정확히 정반대이다.
 64 | 즉 제어권을 다시 역전시킨 것이다.
 65 | 
 66 | 조금 더 간단하게는
 67 | 
 68 | ```js
 69 | var evt = foo(42);
 70 | 
 71 | bar(evt);
 72 | barErr(evt);
 73 | ```
 74 | 
 75 | 이렇게 바뀐다.
 76 | 
 77 | 위의 예시와 아래의 예시를 잘 보면 크게 다른것 같지 않은데? 그냥 코딩스타일 차이 아닌가? 라고 생각할 수 도 있다. 그렇지만 제어권을 기준으로 보자. foo라는 함수가 끝나면 콜스택의 제어권을 누가 가지고 있는지가 중요하다
 78 | 
 79 | ## 리스너를 프로미스로
 80 | 
 81 | 이벤트 리스너가 아니라 프로미스로 조금만 바꿔보자.
 82 | 
 83 | ```js
 84 | function foo(x) {
 85 |   // 어떤 일을 실행하고 프로미스를 반환
 86 | 
 87 |   return new Promise(function(resolve, reject) {});
 88 | }
 89 | 
 90 | var p = foo(42);
 91 | 
 92 | bar(p);
 93 | ```
 94 | 
 95 | 여기서 bar 의 내부를 보자면
 96 | 
 97 | ```js
 98 | function bar(fooPromise) {
 99 |   fooPromise.then(
100 |     function() {}, // resolve 시 작업
101 |     function() {} // reject 시 작업
102 |   );
103 | }
104 | ```
105 | 
106 | 이렇게 되어있을 것이다. 현대의 코드는 then()과 catch()를 많이 사용하지만 기본은 resolve 와 reject 다.
107 | 
108 | 이러한 프로미스는 단 한번만 결과값이 귀결된다. 이 값은 불변성을 가져 변하지 않는다. 믿음을 준다. (믿음성)
109 | 
110 | 단 한번만 결과값이 도출되기에 여러번 호출하지 않고, 값이 변하지 않기 때문에 그 결과로 다른 로직에 이용되도 같은 결과가 도출된다. 또한 에러가 발생하더라도 프로그램의 흐름은 멈추지 않는다. 그냥 예외가 되었기에 버림콜백(reject)로 진행한다.
111 | 
112 | 그렇다면 프로미스가 과연 믿음직스러운건가?? 아직 조금 부족하다.
113 | 


--------------------------------------------------------------------------------
/Deprecated/Promise2.md:
--------------------------------------------------------------------------------
 1 | # Promise2
 2 | 
 3 | ## Promise.resolve()
 4 | 
 5 | 프로미스는 사실 별게 아니다. 콜백을 넘겨주는 위치를 달리했을 뿐이다. foo()에 콜백을 넘기는 것이 아닌 foo()에서 프로미스를 받은 뒤 이 프로미스에 콜백을 준 것이다.
 6 | 
 7 | 프로미스가 나오게 된 가장 중요한 점은 믿음이다.
 8 | 근데 중요한 것은 이 받은 프로미스가 진짜 프로미스가 아니라면? 단지 .then()을 쓸 수 있는 object 라면 어떨까?
 9 | 
10 | 이를 책 *You Don't Know JS*에서는 Thenable 이라고 한다.
11 | 
12 | ```js
13 | var p = {
14 |   then: function(foo, err) {
15 |     foo(42);
16 |     err('하이');
17 |   }
18 | };
19 | 
20 | p.then(
21 |   function resolve(val) {
22 |     console.log(val);
23 |   },
24 |   function rejected(err) {
25 |     console.log(err);
26 |   }
27 | );
28 | ```
29 | 
30 | 이 Object p처럼 then()이 있는 thenable은 모두 프로미스처럼 보이게 동작할 수 있다.
31 | 
32 | 이 경우 Promise.resolve()로 해결이 가능하다. Promise.resolve()를 거치면 이 값으로 이루어진 프라미스 객체가 반환된다.
33 | 
34 | 이게 굉장히 중요하다. 프로미스가 등장한 이유가 믿음성인데 이 믿음성을 해결해준다.
35 | 
36 | ```js
37 | var p1 = new Promise(function(resolve, reject) {
38 |   resolve(42);
39 | });
40 | var p2 = Promise.resolve(42);
41 | 
42 | p1 === p2; // true
43 | ```
44 | 
45 | 자 이제 Thenable 한 값을 Promise.resolve()에 들어가면 정규화시켜보자.
46 | 
47 | ```js
48 | Promise.resolve(p).then(
49 |   function resolve(val) {
50 |     console.log(val);
51 |   },
52 |   function rejected(err) {
53 |     console.log(err); // 실행 안됌
54 |   }
55 | );
56 | ```
57 | 
58 | 자 그럼 이제 할 일은 아래와 같다. 만일 foo()가 어떤 비동기 행위이며 반환값이 프로미스인지 확신하게끔 만들자.
59 | 
60 | ```js
61 | foo(42).then(function(v) {
62 |   console.log(v); // 멍청
63 | });
64 | 
65 | Promise.resolve(foo(42)).then(function(v) {
66 |   console.log(v); // 현명
67 | });
68 | ```
69 | 
70 | 이러면 어떠한 경우에도 무리가 없다. 믿음이 확실해진다.
71 | 
72 | ## 익숙한 ajax
73 | 
74 | 그럼 자주 사용하는 ajax 에 응용해보자.
75 | 
76 | 가장 중요하게 기억해야 할 것은 기존의 콜백은 백그라운드에서 호출, 프로미스는 호출스택에서 호출한다는 점이다.
77 | 
78 | ```js
79 | function request(url) {
80 |   return new Promise(function(resolve, reject) {
81 |     // ajax의 콜백함수가 일반 함수가 아니라 방금 생성한 promise의 resolve가 된다.
82 |     ajax(url, resolve);
83 |   });
84 | }
85 | 
86 | request('https://...')
87 |   .then(function(response1) {
88 |     return request('https://.../?q=' + response1);
89 |   })
90 |   .then(function(response2) {
91 |     console.log(response2);
92 |   });
93 | ```
94 | 
95 | 자주 사용되는 AJAX 공통 코드를 Promise를 이용해서 더욱 믿음을 가지고 사용할 수 있게 될 것이다.
96 | 


--------------------------------------------------------------------------------
/Deprecated/Repaint와 Reflow.md:
--------------------------------------------------------------------------------
  1 | # Repaint와 Reflow
  2 | 
  3 | <br/>
  4 | 
  5 | ## 브라우저의 rendering 과정
  6 | 
  7 | ![rendering](/assets/images/rendering.png)
  8 | 
  9 | 위의 그림과 같이 브라우저는 화면을 rendering하는 과정에서 **배치\(flow\)** 와 **그리기\(paint\)** 의 과정을 거친다.
 10 | 
 11 | <br/>
 12 | 
 13 | ## Reflow의 발생
 14 | 
 15 | 생성된 DOM 노드의 레이아웃이 변경될 떄, 변경 후 영향을 받는 모든 노드를 다시 계산하고 렌더 트리를 재생성 한다.
 16 | 
 17 | 이러한 과정을 `reflow`라 하고 `reflow`가 일어난 후, `repaint`가 일어난다.
 18 | 
 19 | ```javascript
 20 | function reFlow() {
 21 |     var container = document.getElementById('container');
 22 | 
 23 |     container.style.padding = '20px';
 24 |     container.style.border = '20px';
 25 |     container.appendChild(document.createTextNode('hello'));
 26 | }
 27 | 
 28 | ```
 29 | 
 30 | <br/>
 31 | 
 32 | ## Repaint의 발생
 33 | 
 34 | 생성된 DOM 노드에 대하여 style을 변경시켰을 때, **무조건 `reflow`가 발생하진 않는다.**
 35 | **레이아웃 수치에 대한 변경이 일어나지 않는다면, `reflow`가 일어나지 않고, `repaint`만 일어난다.**
 36 | 이러한 경우에는, 색상변경과 같이 레이아웃의 변경이 없는 경우가 있다.
 37 | 
 38 | ```javascript
 39 | function repaint() {
 40 |     var container = document.getElementById('container');
 41 | 
 42 |     container.style.backgroundColor = 'black';
 43 |     container.style.color = 'white';
 44 | }
 45 | 
 46 | ```
 47 | 
 48 | <br/>
 49 | 
 50 | ## Repaint와 Reflow의 최적화
 51 | 
 52 | `Repaint`와 `Reflow`가 많아질수록 애플리케이션의 렌더링 성능은 느려지게 된다.
 53 | 즉, 이를 줄일수록 성능을 높일 수 있다.
 54 | 
 55 | ### DOM객체의 캐싱
 56 | 
 57 | ---
 58 | 
 59 | ```javascript
 60 | //Before
 61 | for(var i=0; i<100; i++) {
 62 | 	document.getElementById('container').style.padding = i + 'px';
 63 | }
 64 | 
 65 | //After
 66 | var container = document.getElementById('container');
 67 | 
 68 | for(var i=0; i<100; i++) {
 69 |     container.style.padding = i + 'px';
 70 | }
 71 | ```
 72 | 
 73 | ### class명과 cssText사용
 74 | 
 75 | ---
 76 | 
 77 | ```javascript
 78 | //Before
 79 | var container = document.getElementById('container');
 80 | 
 81 | container.style.padding = "20px";
 82 | container.style.border = "10px solid red";
 83 | container.style.color = "blue";
 84 | 
 85 | //After cssText
 86 | container.style.cssText = 'padding:20px;border:10px solid red;color:blue;';
 87 | 
 88 | //After class
 89 | container.className = 'test';
 90 | ```
 91 | 
 92 | ### 애니메이션이 들어간 노드는 가급적 position:fixed 또는 position:absolute로 지정
 93 | 
 94 | ---
 95 | 
 96 | ``` javascript
 97 | <div id="animation" style="background:blue;position:absolute;"></div>
 98 | ```
 99 | 
100 | 프레임에 따라 reflow비용이 많은 애니메이션 효과의 경우엔 노드의 `position`을 `absolute`나 `fixed`로 주면 전체 노드에서 분리된다.
101 | 이 경우엔, **전체 노드에 걸쳐 Reflow 비용이 들지 않으며 해당 노드의 Repaint 비용만 들어가게 된다.**
102 | 
103 | ### 테이블 레이아웃을 피한다.
104 | 테이블로 구성된 페이지 레이아웃의 경우, 점진적 페이지 렌더링이 일어나지 않고 모든 계산이 완료된 후, 화면에 렌더링이 되기 때문에 피하는게 좋다.
105 | 
106 | <br/>
107 | 
108 | ## Virtual DOM
109 | 
110 | **Virtual DOM**은 React나 Angular와 같은 UI/UX기반의 라이브러리 혹은 프레임워크에서의 컨셈이 되는 개념이다.
111 | 
112 | 기존에 javascript나 jQuery에서 사용되던 DOM 직접접근 방식의 문제는 reflow와 repaint의 연관성도 빼놓을 수 없다.
113 | 
114 | **DOM은 정적이다.**
115 | DOM 요소에 접근하여 동적으로 이벤트를 주어 layout을 바꾸게 되면 reflow와 repaint가 일어나게 된다.
116 | 
117 | 이 과정에서 규모가 큰 애플리케이션일수록 recalculate할 양이 늘어나고 이는 성능에 큰 영향을 미친다.
118 | 
119 | ### Virtual DOM의 사용
120 | 
121 | > 1. 데이터가 업데이트되면, 전체 UI 를 Virtual DOM 에 리렌더링.
122 | > 2. 이전 Virtual DOM 에 있던 내용과 현재의 내용을 비교.
123 | > 3. 바뀐 부분만 실제 DOM 에 적용.
124 | 
125 | 즉, **Virtual DOM을 사용함으로써 바뀐 부분(Component)만 rerendering하기 때문에 컴포넌트가 업데이트 될 때, 레이아웃 계산이 한 번만 일어나게 된다.**
126 | 
127 | <br/>
128 | 
129 | ---
130 | 
131 | #### Reference
132 | 
133 | - [Reflow or Repaint(or ReDraw)과정 설명 및 최적화 방법](http://webclub.tistory.com/346)
134 | - [DOM의 문제점과 Virtual DOM](https://velopert.com/775)
135 | 
136 | 


--------------------------------------------------------------------------------
/Deprecated/WebWorker.md:
--------------------------------------------------------------------------------
 1 | # Web Worker
 2 | 
 3 | `WebWorker`는 `script` 실행을 메인 쓰레드가 아니라 백그라운드 쓰레드에서 실행할 수 있도록 해주는 기술이다.
 4 | <br/>
 5 | 
 6 | 이 기술을 통해 무거운 작업을 분리된 쓰레드에서 처리할 수 있으며, 이를 통해 메인 쓰레드(일반적으로 UI 쓰레드)는 멈춤, 속도저하 없이 동작할 수 있다.
 7 | <br/>
 8 | 
 9 | ## WebWorker의 개념과 활용
10 | 
11 | `Worker` 는 `Worker()` 생성자를 통해 생성되며 지정된 `Javascript` 파일에 포함된 코드를 `Worker` 쓰레드에서 실행하며, (`Worker`는 현재 `Window` 와 분리된 `DuplicatedWorkerGlobalScope` 라는 별도의 `Global context` 에서 동작) `Worker` 쓰레드에서 어떠한 코드도 실행할 수 있지만, 몇가지 예외가 있다.
12 | <br/>
13 | 
14 | 예를들어 `Worker` 내에서는 `DOM` 을 직접 다룰 수 없다. 또한 `Window` 의 기본 메서드와 속성을 사용할 수 없다.
15 | <br/>
16 | 
17 | `Message System` 을 통해 `Worker` 와 메인 쓰레드 간에 데이터를 교환할 수 있다.
18 | <br/>
19 | 
20 | `Worker.postMessage()` 메서드를 통해 데이터를 전송할 수 있으며, `Worker.onmessage` 이벤트 핸들러 `Attribute` 를 통해 응답할 수 있다. (전송되는 메세지는 `MessageEvent.data` 에 포함). 전송되는 데이터는 공유되지 않으며 복제를 통해 전달되게 된다.
21 | <br/>
22 | 
23 | 부모페이지와 동일한 `Origin` 내에서 `Worker` 는 새로운 `Worker` 를 생성할 수 있다.  `Worker` 들은 `XMLHttpRequest` 를 통해 네트워크 통신을 할 수 있지만 `XMLHttpRequest` 의 `responseXML` 과 `channel attribute` 는 항상 `null` 을 반환한다.
24 | <br/>
25 | 
26 | 지금까지 알아본 `Dedicated Worker` 와 다른 유형의 `Worker`들도 존재한다.
27 | <br/>
28 | 
29 | - `Shared worker` 는 `Worker` 가 동일한 도메인 내에 존재하는 여러 `script` 에 의해 사용될 수 있다. `Shared Worker` 는 `Dedicated worker` 보다 좀더 복잡성을 가지고 있다. 예를들어 `Script` 들은 반드시 활성화된 `Port` 를 통해 통신해야 한다.
30 | - `ServiceWorker` 는 웹 어플리케이션 사이의 `Proxy Server`와 브라우저로서 역할을 하며 (만약 가능하다면)통신을 구축한다. 이를 통해 효율적인 오프라인 경험을 구축하고, 네트워크 요청을 가로채어 통신이 가능한지 여부에 따라 적절한 동작을 수행하며, 서버에 존재하는 자원들을 갱신할 수 있다. 또한 푸시 알림이나 백그라운드 동기화 API에 접근을 허용한다.
31 | - `Chrome Worker` 는 `Firefox` 에서만 사용 가능한 `worker` 유형으로 Add-on을 제작할 때나 확장기능에서 `Worker` 를 사용하고 싶을 때 사용할 수 있으며, `Worker` 에서 `js-ctypes` 에 접근할 수 있다.
32 | - `Audio Workers` 는 스크립트를 통한 직접적인 오디오 처리를 `Web Worker` 에서 처리할 수 있도록 해준다.
33 | 
34 | <br/>
35 | 
36 | ---
37 | 
38 | #### Reference
39 | 
40 | - [MDN-WebWorker](https://developer.mozilla.org/ko/docs/Web/API/Web_Workers_API)
41 | - [MDN 예제](
42 | https://github.com/mdn/simple-web-worker)
43 | 
44 | 
45 | 


--------------------------------------------------------------------------------
/Deprecated/웹 브라우저의 작동 원리.md:
--------------------------------------------------------------------------------
  1 | # 웹 브라우저의 작동 원리
  2 | 
  3 | <br/>
  4 | 
  5 | ## Rendering Engine
  6 | 
  7 | * Webkit Engine : Chrome, Safari
  8 | <br/>
  9 | 
 10 | ![Webkit](/assets/images/Webkit.png)
 11 | 
 12 | * Gecko Engine : Firefox
 13 | <br/>
 14 | 
 15 | ![Gecko](/assets/images/Gecko.jpg)
 16 | 
 17 | <br/>
 18 | 
 19 | ## Critical Rendering Path
 20 | 
 21 | 웹 브라우저가 화면을 그리는데(Rendering) 거치는 주요한 과정
 22 | 
 23 | 1. HTML데이터를 파싱하고 DOM Tree를 빌드.
 24 | 2. 파싱 중 CSS링크를 만나면, CSSOM(CSS Object Model) Tree를 빌드.
 25 | 3. DOM Tree와 CSSOM Tree를 이용해 Render Tree 생성.
 26 | 4. Render Tree의 노드들의 위치를 계산(Layout)
 27 | 5. 화면에 웹 페이지를 그린다.
 28 | 
 29 | <br/>
 30 | 
 31 | ### 1. HTML 데이터 파싱 / DOM Tree 빌드
 32 | 
 33 | ---
 34 | 
 35 | 브라우저는 HTML 데이터를 파싱해 DOM Tree를 만든다.
 36 | 모든 HTML 태그에는 노드가 있고 각각의 노드는 Tree형태로 구현된다.
 37 | 이를 DOM Tree라 한다.
 38 | 
 39 | ```javascript
 40 | <html>
 41 |     <head>
 42 |         <title>BKJang</title>
 43 |     </head>
 44 |     <body>
 45 |         <div>
 46 |         	<button> up </button>
 47 |             middle
 48 |             <button> down </button>
 49 |         </div>
 50 |     </body>
 51 | </html>
 52 | ```
 53 | 
 54 | ### 2. CSSOM Tree 빌드
 55 | 
 56 | ---
 57 | 
 58 | HTML 파싱 중 CSS 링크를 만나면 리소스를 받아온다.
 59 | 받아온 파일은 파싱되고 CSSOM Tree를 빌드한다.
 60 | CSSOM이 구성되어야 다음 과정이 진행된다.(Rendering의 Blocking 요소)
 61 | 
 62 | 
 63 | ### 3. Render Tree 생성
 64 | 
 65 | ---
 66 | 
 67 | DOM Tree와 CSSOM Tree를 결합, Render Tree를 빌드.
 68 | Render Tree는 DOM Tree에 있는 것들 중에 실제 보이는 것들로만 구성.
 69 | **ex) style='display : none;'은 Render Tree에서 제외. 메타태그 역시 제외.**
 70 | 
 71 | 
 72 | Render Tree에는 Render Object Tree, Render Layer Tree, Render Style Tree, InlineBox Tree등이 포함.
 73 | 
 74 | Render Object의 필요에 따라 **Render Layer**가 만들어지고 GPU 처리 여부에 따라 **Graphic Layer** 생성.(하드웨어 가속)
 75 | 
 76 | 기본적으로 Layer는 하나고 CPU가 렌더링에 주요한 역할.
 77 | 
 78 | * CSS 3D Transform(translate3d, preserve-3d 등)이나 perspective 속성이 적용된 경우
 79 | 
 80 | * CSS 애니메이션함수나 필터함수를 사용하는 경우
 81 | 
 82 | * video나 canvas 요소를 사용하는 경우
 83 | 
 84 | * 자식 요소가 레이어로 구성된 경우
 85 | 
 86 | * z-index가 낮은 형제 요소가 레이어로 구성된 경우
 87 | 
 88 | 
 89 | ### 4. Layout
 90 | 
 91 | ---
 92 | 
 93 | Render Tree가 만들어지고, 각각의 노드들의 위치를 계산하는 과정.
 94 | 위치 관련된 속성 계산(position, width, height 등).
 95 | 
 96 | **ex) width:100%인 상태에서 브라우저를 리사이즈하면, Render Tree는 변경되지 않고 Layout 이후 과정만 다시 거치게 된다.**
 97 | 
 98 | #### 5. Paint
 99 | 
100 | 실제 웹페이지를 화면에 그리는 작업.
101 | 
102 | **색이 바뀐다거나 노드의 스타일이 바뀌는 걸로는 Layout 과정을 거치지 않고 Paint만 일어난다.**
103 | 
104 | 
105 | <br/>
106 | 
107 | ## CSS와 JavaScript의 위치
108 | 
109 | 브라우저의 렌더링 과정에서 DOM Tree를 빌드한 후, 스타일 규칙이 없으면 Rendering이 불가.
110 | 
111 | 인터프리터은 HTML을 위에서 아래로 읽기 때문에 CSS를 `<head></head>`태그 사이에 두면 CSS 리소스를 최대한 빨리 받을 수 있다.
112 | 
113 | 반면, JavaScript는 DOM객체를 컨트롤하기 때문에 CSS처럼 위에 두게 되면 파싱을 멈추고 스크립트 파일을 읽기 때문에 성능이 저하된다. 따라서, JavaScript 소스는 주로 `</body>`태그 위에 모아두는게 좋다.
114 | 
115 | 단, 이런 경우 JS 애니메이션이 나중에 적용되어 사용자 입장에서 깜빡임 현상이 생길 수 있기 때문에 애니메이션 부분만 `<head></head>`사이에 두는 것도 방법이다.
116 | 
117 | <br/>
118 | 
119 | ---
120 | 
121 | #### Reference
122 | 
123 | - [Naver D2 - 브라우저의 작동 원리](http://d2.naver.com/helloworld/59361)
124 | - [브라우저가 웹페이지를 그리는 법](https://isme2n.github.io/devlog/2017/07/06/browser-rendering/)
125 | - [웹브라우저에서 HTML문서 렌더링 과정](http://jeong-pro.tistory.com/90)
126 | 
127 | 


--------------------------------------------------------------------------------
/Deprecated/점진적향상_우아한하향.md:
--------------------------------------------------------------------------------
 1 | # 점진적 향상, 우아한 하향
 2 | 
 3 | 2가지 개발접근법이 있다. 우아한 낮춤과 점진적인 향상.<br/>
 4 | 간단히 정리하자면 다음과 같이 정의할 수 있다.
 5 | <br/>
 6 | 
 7 | ## 우아한 낮춤(Graceful degradation)
 8 | 
 9 | - 원하는 기능을 갖는 또다른 버전을 제공하거나, 사용자가 제품의 결점이 사용성을 보장하기 위한 안전 조치때문이라는 것을 인지하도록 만드는 것이다.
10 | - 최신 기술 기반 또는 기기에서 동작하는 기능을 만들고 나서 오래된 기술 기반 혹은 기기에서도 유사한 성능으로 동작하도록 조치하는 것이다.
11 | - 사용자들의 기기를 위해 별도의 버전을 만들어 놓는 것이다.
12 | 
13 | <br/>
14 | 
15 | ex) 사용자의 브라우저가 javascript를 지원하지 않을 때
16 | 
17 | - js를 지원하지 않는 기기를 위해 <noscript> 태그를 사용하여 사용자에게 "javascript가 지원되는 브라우저를 사용해 주세요!" 와 같은 알람을 띄워주는 것
18 | 
19 | <br/>
20 | 
21 | ## 점진적 향상(Progressive enhancement)
22 | 
23 | - 사용가능한 기능을 바탕으로, 향상된 기능을 적용하기 전에 테스트를 통해 풍부한 사용자 경험을 하나씩 증가시키는 것이다.
24 | - 많은 테스트를 통해 말그대로 기능을 점진적으로 향상시키는 것.
25 | - 기초부터 차곡차곡 쌓아서 발전해 나가는 방법
26 | 
27 | <br/>
28 | 
29 | ex ) 웹 페이지를 구성할 때
30 | 
31 | 1. HTML로 마크업을 구성한다.
32 | 2. CSS로 스타일을 입힌다.
33 | 3. JS로 사용자 경험을 향상 시킨다.
34 | 
35 | <br/>
36 | 
37 | ---
38 | 
39 | #### Reference 
40 | 
41 | - [적절한 낮춤 대 점진적 향상](http://www.clearboth.org/51_graceful_degradation_versus_progressive_enhancement/)


--------------------------------------------------------------------------------
/Design_Pattern/MVC1, MVC2.md:
--------------------------------------------------------------------------------
 1 | # MVC1 vs MVC2
 2 | 주제를 무엇으로 하면 좋을까 생각하다가 MVC model에는  `MVC1`, `MVC2` 이렇게 두 가지 모델이 있다는 것을 발견하였다. 
 3 | 
 4 | 생소한 단어였기 때문에 정리를 해보았다.
 5 | 
 6 | ## MVC
 7 | 우선 MVC란 `Model`, `View`, `Controller`의 줄임말로써 사용자와 상호작용하는 S/W를 디자인함에 있어 세 가지 요소로 쪼개어 하는 것을 가리킨다. 
 8 | 
 9 | ### MVC를 사용하는 이유
10 | 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있기 때문에 사용한다.
11 | 
12 | 예를 들어 디자인이 수시로 바는 경우 로직을 분리하지 않으면 서로 영향 없이 코드를 고치기에는 쉽지 않을 것이다. 
13 | 
14 | MVC 모델을 사용한다면 유지 보수 및 확장성을 높일 수 있다. 
15 | 
16 | **1. Model**
17 | > 프로그램의 내부 상태, 내부 비즈니스 로직을 처리하기 위한 역할이다.
18 | 
19 | **2. Controller**
20 | > 사용자의 입력 처리와 흐름 제어를 담당하고 뷰와 모델을 분리하는 역할을 한다.
21 | 
22 | **3. View**
23 | > 사용자 인터페이스 요소를 뜻하는데, 유저에게 보여주는 화면을 말한다. 
24 | 
25 | ## MVC1
26 | 쉽게 말해 `M+(V+C)`라고 보면 된다.
27 | 
28 | - 웹 브라우저의 요청을 jsp 페이지가 받아서 처리하는 구조이고, **JSP가 Controller와 View의 기능을 모두 담당**한다.
29 | - jsp 페이지에 비즈니스 로직을 처리하기 위한 코드와 웹 브라우저에 결과를 보여주기 위한 출력 관리 코드가 뒤섞여 있는 구조이다.
30 | - jsp 내부에서 java로 Controller의 기능을 수행한다. view는 HTML과 CSS로 처리하고 event 처리 및 제어는 javascript로 실행한다.
31 | - 재사용이 힘들고, 코드가 뒤섞여 있어 가독성이 떨어진다.
32 | > 많은 프로세싱이 요구되는 대형 프로젝트의 경우 적합하지 않다.
33 | 
34 | MVC1의 이해를 돕기 위해 [예제](https://itsaessak.tistory.com/64)을 참고하길 바란다. 
35 | 
36 | ![MVC1 model](https://user-images.githubusercontent.com/43868540/88455376-c18c0880-ceaf-11ea-90b2-fcf2be11b7f6.png)
37 | - [출처 creator0609.tistory](https://creator0609.tistory.com/entry/MVC1-MVC2-차이)
38 | 
39 | ### 장점
40 | - 단순해서 **개발 시간 단축**에 유리하다.
41 | - **중소형 프로젝트**에 적합하다.
42 | 
43 | #### 단점
44 | - 웹 애플리케이션이 복잡해질수록 유지 보수가 힘들어진다.
45 | - 디자이너와 개발자 간의 원활한 소통이 필요하다.
46 | 
47 | ## MVC2
48 | 일반적으로 MVC라고 하면 MVC2모델을 이야기한다고 보면 된다.
49 | 
50 | - MVC1 구조와 달리 웹 브라우저의 요청을 하나의 `서블릿`이 받게 된다. 여기서 서블릿은 `controller`이다. 
51 | - `서블릿`은 웹 브라우저의 요청을 알맞게 처리한 후 그 결과를 jsp 페이지로 넘기게 된다.
52 | > 서블릿은 웹 프로그래밍에서 클라이언트의 요청을 처리하고 그 결과를 다시 클라이언트에게 전송하는 자바 프로그래밍을 이야기한다. 
53 | - 요청 처리, 데이터 접근, 비즈니스 로직을 포함하는 **Controller와 View가 엄격히 구분**되어 있다. 
54 | > 대형 프로젝트의 경우에는 적합하나 구조 설계를 위한 충분한 시간이 필요하다. 
55 | 
56 | MVC2의 예제도 [이곳](https://itstudyroom.tistory.com/entry/MVC2-게시판-2-로그인)을 참고하면 MVC1모델과는 다른 것을 확인할 수 있다.
57 | 
58 | ![MVC2 model](https://user-images.githubusercontent.com/43868540/88455358-a5886700-ceaf-11ea-9be5-38e234dbfd7c.png)
59 | - [출처 creator0609.tistory](https://creator0609.tistory.com/entry/MVC1-MVC2-차이)
60 | 
61 | ### 전체적인 컴포넌트 설계
62 | ![전체적인 컴포넌트 설계](https://user-images.githubusercontent.com/43868540/88455435-39f2c980-ceb0-11ea-8123-4e31d9db21e1.png)
63 | - [출처 creator0609.tistory](https://creator0609.tistory.com/entry/MVC1-MVC2-차이)
64 | 
65 | ### 장점
66 | - 비즈니스 로직과 뷰가 분리되어 **유지 보수 및 확장성**이 뛰어나기 때문에 큰 프로젝트에서 사용된다.
67 | - 개발자, 디자이너의 역할이 분리되어 **책임이 분명**해진다.
68 | 
69 | ### 단점
70 | - 개발 초기 비용 증가 및 개발 기간이 늘어난다. 
71 | ----
72 | #### Reference
73 | - [MVC1과 MVC2의 개념](https://nickjoit.tistory.com/9)
74 | - [MVC1,2의 장단점](http://blog.naver.com/PostView.nhn?blogId=koliaok&logNo=220566166684&categoryNo=0&parentCategoryNo=0&viewDate=&currentPage=1&postListTopCurrentPage=1&from=postView)
75 | 


--------------------------------------------------------------------------------
/Design_Pattern/MVC_MVP_MVVM.md:
--------------------------------------------------------------------------------
  1 | # MVC, MVP, MVVM
  2 | 
  3 | 간단하게 많이 사용하는 패턴을 정리를 해보자.
  4 | <br/>
  5 | 
  6 | 웹개발시 쓰이는 패턴들은 다양하게 존재한다.<br/>
  7 | 그 중에서 3개를 보게되면 공통점은 모두 화면에 보여주는 로직과 실제 데이터가 처리 되는 로직이 분리되어 있다는 것이다.
  8 | <br/>
  9 | 
 10 | 솔직히 패턴을 사용하지 않고도 충분히 짤 수는 있겠지만 모든 것은 나중에 한 번에 터지듯이 쌓이다 보면 한꺼번에 리팩토링을 하기에는 무리가 있는 것이다.
 11 | <br/>
 12 | 
 13 | ## **MVC (Model + View + Controller)**
 14 | 
 15 | MVC 패턴은 3가지의 요소로 구성이 되어있다.
 16 | <br/>
 17 | 
 18 | - Controller : 사용자의 입력을 받고 처리하는 부분
 19 | - Model : 프로그램에서 사용되는 실제 데이터 및 데이터 조작 로직을 처리하는 부분
 20 | - View : 사용자에게 제공되어 보여지는 UI 부분
 21 | 
 22 | <br/>
 23 | 
 24 | 처음 알게된 패턴이 바로 이 패턴이었다. 당시 내용은 스프링으로 작업을 할 때 많이 봤었다. 
 25 | <br/>
 26 | 
 27 | ![MVC](https://github.com/SeonHyungJo/FrontEnd-Dev/blob/master/assets/image/MVC.png?raw=true)
 28 | 
 29 | <br/>
 30 | 
 31 | 1. 사용자가 처음 주소를 입력하고 Enter를 누르게 되면 `Controller`에 먼저 요청이 들어간다.
 32 | 2. 이에 `Controller`는 해당 주소에 맞는 데이터를 `Model`에 요청을 하며 불러오게 되고,
 33 | 3. `Model`은 해당 데이터들을 보여줄 `View`를 선택해서 화면에 보여주게 된다.
 34 | 
 35 | <br/>
 36 | 
 37 | **MVC의 단점은 View와 Model이 서로 의존적이라는 점이다.**
 38 | <br/>
 39 | 
 40 | ## **MVP (Model + View + Presenter)**
 41 | 
 42 | 여기서는 한눈에 보아도 눈에 띄는 것은 바로 `Presenter`입니다.
 43 | <br/>
 44 | 
 45 | - Presenter : `View`에서 요청한 정보를 `Model`로 부터 가공해서 `View`로 전달하는 부분
 46 | - Model : 프로그램에서 사용되는 실제 데이터 및 데이터 조작 로직을 처리하는 부분
 47 | - View : 사용자에게 제공되어 보여지는 UI 부분
 48 | 
 49 | <br/>
 50 | 
 51 | 이제 사용자의 입력의 시작은 `View`에서 시작을 한다. 이에 `Presenter`는 `Model`과 `View`의 중간자 역할을 한다. 데이터를 처리하는 `Model`과 `View`는 서로 의존성이 떨어지게 된다.
 52 | <br/>
 53 | 
 54 | ![MVP](https://github.com/SeonHyungJo/FrontEnd-Dev/blob/master/assets/image/MVP.png?raw=true)
 55 | 
 56 | <br/>
 57 | 
 58 | 1. `View`로 사용자의 입력이 들어옵니다.
 59 | 2. `View`는 `Presenter`에 작업 요청을 합니다.
 60 | 3. `Presenter`에서 필요한 데이터를 `Model`에 요청 합니다.
 61 | 4. `Model`은 `Presenter`에 필요한 데이터를 응답 합니다.
 62 | 5. `Presenter`는 `View`에 데이터를 응답 합니다.
 63 | 6. `View`는 `Presenter`로부터 받은 데이터로 화면에 보여주게 됩니다.
 64 | 
 65 | <br/>
 66 | 
 67 | 이것의 단점은 이제 `Model`과 `View`의 의존성은 떨어지게 되었지만 **`View`와 `Presenter`가 1:1로 강한 의존성을 가지게 된다는 것입니다.**
 68 | <br/>
 69 | 
 70 | ## **MVVM (Model + View + ViewModel)**
 71 | 
 72 | 이제는 `Presenter`, `Controller`대신하여 `ViewModel`이라는 것이 생겼습니다.
 73 | <br/>
 74 | 
 75 | - ViewModel : `View`를 표현하기 위해 만들어진 `View`를 위한 `Model`
 76 | - Model : 프로그램에서 사용되는 실제 데이터 및 데이터 조작 로직을 처리하는 부분
 77 | - View : 사용자에게 제공되어 보여지는 UI 부분
 78 | 
 79 | <br/>
 80 | 
 81 | `MVVM`은 **2가지 디자인 패턴을 사용한다고 한다.** 바로 `Command패턴`과 `DataBinding`입니다.
 82 | <br/>
 83 | 
 84 | 위의 2가지 패턴으로 인해 `View`와 `ViewModel`은 의존성이 완전히 사라지게 됩니다.
 85 | <br/>
 86 | 
 87 | `MVP`과 마찬가지로 `View`에서 입력이 들어오며, 입력이 들어오게 되면 `Command`패턴을 통해 `ViewModel`에 명령을 내리게 되고(Action) `DataBinding`으로 인해 `ViewModel`의 값이 변화하면 바로 `View`의 정보가 바뀌에 되는 것입니다.
 88 | <br/>
 89 | 
 90 | ![MVVM](https://github.com/SeonHyungJo/FrontEnd-Dev/blob/master/assets/image/MVVM.png?raw=true)
 91 | 
 92 | <br/>
 93 | 
 94 | 1. `View`에 입력이 들어오면 `Command`패턴으로 `ViewModel`에 명령을 합니다.
 95 | 2. `ViewModel`은 필요한 데이터를 `Model`에 요청 합니다.
 96 | 3. `Model`은 `ViewModel`에 필요한 데이터를 응답 합니다.
 97 | 4. `ViewModel`은 응답 받은 데이터를 가공해서 저장 합니다.
 98 | 5. `View`는 `ViewModel`과의 `Data Binding`으로 인해 자동으로 갱신 됩니다.
 99 | 
100 | <br/>
101 | 
102 | 위와 같은 **MVVM 패턴**은 SPA에서 리액트나 뷰의 진형에서 사용되고 있는 패턴이다. 모든 패턴들이 완벽하지는 않다 시간이 지나고 사용을 하면서 발전하는 것이 바로 패턴인 것이다. :running:
103 | 
104 | ---
105 | 
106 | #### Reference
107 | 
108 | - [마기의 개발블로그](https://magi82.github.io/android-mvc-mvp-mvvm/)


--------------------------------------------------------------------------------
/Design_Pattern/Memoization.md:
--------------------------------------------------------------------------------
  1 | # Memoization
  2 | 
  3 | `React` 10월 말을 기준으로 **새로운 릴리즈**가 올라왔다.
  4 | <br/>
  5 | `React.memo`라는 새로운 기능이 나오게 되었다.
  6 | <br/>
  7 | 
  8 | 최근 회사에서 사용하는 `vue`의 컴포넌트를 1300개 가량을 그리게 되면 13초의 시간이 걸리는 이슈가 생겨서 생각을 하고 있었는데 `React`에서는 16.6버전에 `Memoization`기능이 추가가 되었다. 더 많은 기능의 설명은 해당 주소로 이동하면 된다.
  9 | <br/>
 10 | 
 11 | `Memoization`을 간단하게 말을 하자면 컴포넌트를 캐시를 해놓고 같은 컴포넌트를 만들때 캐시된 내용을 먼저 보고 있다면 새로 만드는 것이 아닌 캐시된 컴포넌트 내용을 보고 만드므로써 성능, 속도를 향상 시키는 것이다.
 12 | <br/>
 13 | 
 14 | 그렇다면 js에서는 어떻게 사용할 수 있을까?
 15 | <br/>
 16 | 
 17 | 자바스크립트에서는 반복적으로 계산되는 함수는 **메모이제이션 패턴**으로 구현을 한다.
 18 | <br/>
 19 | 
 20 | 계산 결과를 저장해 놓아 이후에 **다시 계산할 필요없이 사용가능하도록 저장해놓은 캐싱과 같은 기능 메모이제이션**이라고 한다.
 21 | <br/>
 22 | 
 23 | 가장 좋은 예시는 피보나치 수열로 하는 것이다.
 24 | 기존의 3!에서 4!을 다시 구하는데 있어서 새로 처음부터 계산을 해나가는 것이 아니다.
 25 | <br/>
 26 | 
 27 | 아래에서 피보나치수열로 예를 들어보도록 하자.
 28 | <br/>
 29 | 
 30 | 피보나치수열은 `0, 1, 1, 2, 3, 5, 8, 13, 21, ... `으로 나타나는 수열이다.
 31 | <br/>
 32 | 
 33 | ## 일반코드 \#1
 34 | 
 35 | ```js
 36 | function fibonacci(n) {
 37 |     if (n < 2) {
 38 |          return n;
 39 |     }
 40 |     else {
 41 |          return fibonacci(n-1) + fibonacci(n-2);
 42 |     }
 43 | }
 44 | fibonacci(5);
 45 | ```
 46 | 
 47 | <br/>
 48 | 
 49 | ## 일반코드 \#2
 50 | 
 51 | 삼항연산자를 사용하여 코드 정리
 52 | 
 53 | ```js
 54 | function fibonacci(n) {
 55 |     return n < 2 ? n : fibonacci(n-1) + fibonacci(n-2);
 56 | }
 57 | fibonacci(5);
 58 | ```
 59 | 
 60 | <br/>
 61 | 
 62 | ## Memoization을 사용한 코드 \#3
 63 | 
 64 | `memo` 배열에 계산한 값을 저장해 놓은 후, 다시 계산하지 않고 사용하도록 개선
 65 | 
 66 | ```js
 67 | let memo = [0,1];
 68 | 
 69 | function fibMemoization(n) {
 70 |    if(typeof memo[n] !== 'number') {
 71 |      memo[n] = fibMemoization(n-1) + fibMemoization(n-2);
 72 |    }
 73 |    return memo[n];
 74 | }
 75 | fibMemoization(5);
 76 | ```
 77 | 
 78 | 연산할 값이 크면 클수록 `Memoization`을 사용했을 때와 하지 않았을때의 성능은 크게 차이가 난다.
 79 | <br/>
 80 | 
 81 | 재귀적으로 `fibonacci`함수를 몇번 호출하는지 비교를 통해서 알아볼 수 있다.
 82 | <br/>
 83 | 
 84 | ```js
 85 | var count = 0;
 86 | 
 87 | function fib(n) {
 88 |    count++;
 89 |    console.log('called fib: ', count);
 90 |    return n<2 ? n : fib(n-1) + fib(n-2);
 91 | }
 92 | 
 93 | var beforeDate = new Date();
 94 | 
 95 | fib(15);
 96 | 
 97 | var afterDate = new Date();
 98 | 
 99 | console.log(afterDate - beforeDate);
100 | ```
101 | 
102 | <br/>
103 | 
104 | ```js
105 | var memo = [0,1];
106 | var count = 0;
107 | 
108 | function fibMemoization(n) {
109 |    count++;
110 |    console.log('called fibMemoization: ', count);
111 |    if(typeof memo[n] !== 'number') {
112 |      memo[n] = fibMemoization(n-1) + fibMemoization(n-2);
113 |    }
114 |    return memo[n];
115 | }
116 | 
117 | var beforeDate = new Date();
118 | 
119 | fibMemoization(15);
120 | 
121 | var afterDate = new Date();
122 | 
123 | console.log(afterDate - beforeDate);
124 | ```


--------------------------------------------------------------------------------
/Design_Pattern/Throttle and Debounce.md:
--------------------------------------------------------------------------------
 1 | # 쓰로틀링과 디바운싱
 2 | 
 3 | ## 공통점
 4 | 
 5 | 함수를 호출할 때 호출이 너무 많이 되어 과부화 됨을 방지하기 위한 장치다.
 6 | 
 7 | 함수 호출이 잦은 예로는 브라우저의 이벤트가 있다. onscroll 이나 onchange 와 같은 이벤트의 콜백으로 함수를 호출하는 경우 굉장히 많은 호출이 발생할 수 있다.
 8 | 
 9 | ## 예시
10 | 
11 | infinite scroll 이나 자동완성 기능의 경우 사용자의 특정 이벤트에 따라 비동기 콜백을 호출하는 방식이다. 이 경우 이벤트가 매우 빈번하게 일어나며, 많은 호출을 제어하지 않으면 브라우저가 버티지 못할 것이다. 이때 사용하는것이 쓰로틀링과 디바운싱이다.
12 | 
13 | ## 차이점
14 | 
15 | ### 쓰로틀링
16 | 
17 | ---
18 | 
19 | Throttle 은 정해진 시간동안 특정 행위를 한 번만 호출하도록 하는 것이다. 예를 들어 스크롤 행위가 1 초에 500 번이 발생한다면 이를 0.2 초에 한 번만 실행하게 만들 수 있다. Throttle 처리가 되지 않은 경우 콜백이 500 번 발생한다. 하지만 Throttle 처리가 된다면 5 번만 실행되게 만드는 기술이다.
20 | 
21 | 생각보다 스크롤 이벤트의 경우 작은 움직임에도 엄청나게 많은 이벤트가 발생한다. 따라서 1 초 미만으로 쓰로틀링을 하여 같은 동작의 여러번 호출을 1 번으로 제어하는 것이 좋겠다.
22 | 
23 | ### 디바운싱
24 | 
25 | ---
26 | 
27 | Debounce 는 한 행위를 여러번 반복하는 경우, 마지막 행위 이후 특정 시간이 흐른 뒤에 콜백을 호출하도록 하는 방식이다. 말이 되게 어려운데 자동완성 즉 autocomplete 를 떠올리면 편하다.
28 | 
29 | 자동완성을 구현해본다고 생각하자.
30 | input 의 `onChange`가 일어나면 callback 으로 AJAX 를 이용해 관련 데이터를 긁어온다. 그런데 사용자의 모든 입력에 AJAX 호출을 한다면 브라우저가 견디지 못할 것이다. 그래서 일정시간동안 Timer 를 만든다. 이 타이머의 시간동안 입력이 발생해 변경이 일어나면 Timer 를 초기화 한다. 입력이 멈추어 Timer 가 다 되면 AJAX 를 호출한다.
31 | 
32 | 이를 가장 쉽게 눈으로 볼 수 있게 만든 곳이 아래입니다.
33 | [CSS-Tricks 의 Throttling 과 Debouncing](https://css-tricks.com/debouncing-throttling-explained-examples/)
34 | 
35 | Throttling 과 Debouncing 은 실제로 개발 시 자주 사용되는 기술이다. 따라서 좋은 라이브러리가 만들어져 있다. [Lodash](https://lodash.com/) 와 [Underscore](https://underscorejs.org/) 를 사용해보자.
36 | 


--------------------------------------------------------------------------------
/ECMAScript/Destructuring_Assignment.md:
--------------------------------------------------------------------------------
 1 | # 구조 분해 할당
 2 | 
 3 | ```js
 4 | const { store } = this.props;
 5 | ```
 6 | 
 7 | 오른쪽의 객체에서 원하는 부분만 뽑아 사용하는 저런 구문을 react에서 처음 접했다. 처음엔 신기해서 그냥 쓰다가 어느 순간 궁금해지기 시작하여 이번에 다루어 봤다.
 8 | 
 9 | 위처럼 오른쪽의 특정 값을 해체하여 왼쪽에 할당하는 표현식(expression)을 destructuring assignment라고 한다.
10 | 
11 | 이 표현식은 ES6부터 추가 되었으며 배열이나 객체의 속성을 분해하여 다룰 수 있다.
12 | 
13 | ## 배열
14 | 
15 | ```js
16 | var x = [0, 1, 2, 3, 4, 5];
17 | var [a, b, , c] = x;
18 | console.log(a, b, c); // 0 1 3
19 | ```
20 | 
21 | 말로 설명해야 할까 싶을 정도로 단순하다. line 2의 코드의 우변의 배열에서 각각 해당하는 요소들을 우변의 변수에 할당해준다.
22 | 
23 | 이는 파이썬과 같은 언어들에서 찾아 볼 수 있다.
24 | 
25 | ### 응용
26 | 
27 | ---
28 | 
29 | 이를 응용하는 방식으로는 대표적으로 변수의 값 교환(swap)하는 알고리즘을 간단히 바꿀 수 있다.
30 | 
31 | ```js
32 | var x = 1;
33 | var y = 2;
34 | var tmp = x;
35 | 
36 | x = y;
37 | y = tmp;
38 | 
39 | console.log(x, y);
40 | ```
41 | 
42 | 보통의 경우 swap은 간단하게 이렇게 구현한다. 그런데 구조 분해 할당을 이용하면 매우 간결해진다.
43 | 
44 | ```js
45 | var x = 1;
46 | var y = 2;
47 | 
48 | [x, y] = [y, x];
49 | console.log(x, y);
50 | ```
51 | 
52 | 조금 더 나아가 sperad operator를 함께 사용할 수도 있다.
53 | 
54 | ```js
55 | var [x, ...y] = [1, 2, 3];
56 | console.log(x); // 1
57 | console.log(y); // [2, 3]
58 | ```
59 | 
60 | ## 객체
61 | 
62 | ```js
63 | var x = { a: 1, b: 'hello' };
64 | var { a, b } = x;
65 | 
66 | console.log(a, b); // 1, 'hello'
67 | ```
68 | 
69 | 배열을 잘 이해했다면 딱히 어려움 없이 이해할 수 있다. `x.a`와 `x.b`를 각각 전역스코프 변수 a와 b에 할당한다.
70 | 
71 | ### 응용
72 | 
73 | ---
74 | 
75 | 위와 같이 사용하면 변수의 이름은 a와 b밖에 사용하지 못한다. 전역스코프의 변수명을 다르게 하고 싶다면 아래와 같이 사용 가능하다.
76 | 
77 | ```js
78 | var x = { a: 1, b: 'hello' };
79 | var { a: count, b: text } = x;
80 | 
81 | console.log(count, text); // 1, 'hello'
82 | ```
83 | 
84 | 또한 객체에서도 마찬가지로 sperad operator를 사용할 수 있습니다.
85 | 
86 | ```js
87 | var x = { a: 1, b: 'hello', c: 2, d: true };
88 | var { a, b, ...rest } = x;
89 | 
90 | console.log(a, b, c); // 1, 'hello', {c: 2, d: true}
91 | ```
92 | 


--------------------------------------------------------------------------------
/ECMAScript/Includes_IndexOf.md:
--------------------------------------------------------------------------------
 1 | # Includes와 IndexOf
 2 | 
 3 | ## 소개
 4 | 
 5 | 두 메서드 모두 배열에 어떤 값이 있는지 찾을 때 비슷하게 사용한다. 정확히는 사용 용도가 조금은 다르지만, 배열에 어느 값이 있는지 확인할 때 사용할 수 있다. includes는 ES6부터 새로 생긴것인데 어떤 차이점이 있는지 알고 왜 이 메서드를 사용해야하는지 알아보자.
 6 | 
 7 | ## 공통점
 8 | 
 9 | includes는 boolean을, indexOf 는 Number를 반환한다. indexOf는 찾고자하는 값이 있는 배열의 숫자를 반환하고 없으면 -1을 반환한다.
10 | 
11 | 아래와 같이 사용할 수 있다.
12 | 
13 | ```javascript
14 | const array = [0, 1, 2, 3, 4];
15 | 
16 | array.includes(2) ? console.log('yes') : console.log('no');
17 | array.indexOf(2) > -1 ? console.log('yes') : console.log('no');
18 | ```
19 | 
20 | ## 차이점
21 | 
22 | 배열 안의 값이 조금 특별해지면 이야기가 달라진다.
23 | 
24 | ```javascript
25 | const array = [1, null, NaN, , -0]; // 빈값은 undefined
26 | 
27 | array.includes(1) ? console.log('yes') : console.log('no');
28 | array.indexOf(1) > -1 ? console.log('yes') : console.log('no');
29 | 
30 | array.includes(null) ? console.log('yes') : console.log('no');
31 | array.indexOf(null) > -1 ? console.log('yes') : console.log('no');
32 | 
33 | // 달라지는 구간
34 | array.includes(NaN) ? console.log('yes') : console.log('no');
35 | array.indexOf(NaN) > -1 ? console.log('yes') : console.log('no');
36 | 
37 | array.includes(undefined) ? console.log('yes') : console.log('no');
38 | array.indexOf(undefined) > -1 ? console.log('yes') : console.log('no');
39 | 
40 | // 둘다 버그
41 | array.includes(+0) ? console.log('yes') : console.log('no');
42 | array.indexOf(+0) > -1 ? console.log('yes') : console.log('no');
43 | ```
44 | 
45 | 1, null에는 큰 이상이 없지만 NaN, undefined는 includes만 잡아낸다. -0, +0은 모두 잡지 못한다.
46 | 
47 | ## 결론
48 | 
49 | 배열안의 값을 확인하는 경우 큰 차이는 없지만 NaN, undefined와 관련한 버그가 발생할 수 있다. 따라서 이왕이면 includes를 사용하는 것이 더 좋아보인다.
50 | 


--------------------------------------------------------------------------------
/ECMAScript/Number_isNaN.md:
--------------------------------------------------------------------------------
 1 | # isNaN
 2 | 
 3 | ## NaN
 4 | 
 5 | NaN은 Not a Number이다. 그런데 이건 조금 특이하다. 단순히 숫자가 아닌것이 아니다. 조금 정확히 하자면 Not a Number 보다는 Invaild Number라는 표현이 조금 더 정확할 것 같다. 무슨말이나면 숫자긴 숫자인데 에러가 발생하는 숫자라는 의미다.
 6 | 
 7 | ```javascript
 8 | var a = 2 / 'hello';
 9 | 
10 | typeof a; // 'number'
11 | ```
12 | 
13 | NaN은 연산의 결과에서 에러가 발생(undefined or unpresentable) 할 때 생성된다. 위의 경우처럼 숫자를 문자열로 나누는 것처럼 말이다.
14 | 
15 | ## NaN의 비교 (isNaN())
16 | 
17 | 너무 유명한 주제인데 NaN은 서로 동등비교 할 수 없다. NaN은 자신과도 같지 않기 때문이다.
18 | 
19 | ```javascript
20 | var a = NaN;
21 | 
22 | a === a; // false
23 | a === NaN; // false
24 | ```
25 | 
26 | 그래서 내장 전역 함수인 isNaN()을 사용했었다.
27 | 그런데 치명적인 문제는 이 역시 의미가 모호하다. 이유는 메커니즘에 있다. 주어진 인자 x 가 Number가 아니라면 Number(x)의 형태로 강제 형변환을 한 뒤 이게 NaN인지 비교하는 방식이다.
28 | 
29 | ```javascript
30 | isNaN(NaN); // true
31 | isNaN('hello'); // true
32 | isNaN('37'); // false
33 | ```
34 | 
35 | 즉 isNaN은 NaN인지는 확인이 가능하다. 그러나 `"hello"` 와 같이 NaN이 아닌 값도 NaN으로 판단한다. 즉 숫자로 강제 변환되지 않는 값은 NaN으로 취급하는 에러가 발생한다.
36 | 
37 | 따라서 `isNaN("NaN") // true` 이런 일도 발생해 버린다.
38 | 
39 | ## NaN의 비교 (Number.isNaN())
40 | 
41 | ES6부터 이를 해결하기 위해 Number.isNaN()라는 메서드가 등장했다. 원래의 전역 isNaN보다 조금 더 엄격한 버전이다.
42 | 
43 | ```javascript
44 | Number.isNaN(NaN); // true
45 | Number.isNaN('hello'); // false
46 | Number.isNaN('37'); // false
47 | Number.isNaN('NaN'); // false
48 | ```
49 | 
50 | 아주 직관적으로 잘 작동한다. 그런데 ES6부터기 때문에 폴리필이 필요할 수 있다. 폴리필을 보면 코드가 실제로 어떻게 작동하는지 알수 있기 때문에 유용한데 안은 정말정말 간단하게 되어있다.
51 | 
52 | ```javascript
53 | Number.isNaN =
54 |   Number.isNaN ||
55 |   function(value) {
56 |     return value !== value;
57 |   };
58 | ```
59 | 
60 | 한줄이 끝이다. `value !== value` 인 것만 확인하면 된다. 생각보다 매우 잘 작동한다. 혹시 isNaN을 사용할 일이 있다면 에러가 발생할 수 있기 때문에 모두 Number.isNaN으로 바꿔주도록 하자.
61 | 


--------------------------------------------------------------------------------
/ECMAScript/Spread_Operator.md:
--------------------------------------------------------------------------------
  1 | # Spread Operator
  2 | 
  3 | ## 전개 연산자
  4 | 
  5 | ES2015인 ES6부터 새롭게 추가된 연산자다. 배열을 각 요소로 확장하는 연산자다. 생긴건 `...` 이렇게 생겼다. 말로 설명하자면 좀 복잡하고 개발자답게 코드로 보는 것이 가장 쉽다.
  6 | 
  7 | 그런데 대표적인(typically) 예가 좀 애매하다. 이 전개 연산자는 여러가지를 대체할 수 있기 때문이다. 그래서 몇가지 예시 찾아봤다.
  8 | 
  9 | ## 기존의 문제점
 10 | 
 11 | ```js
 12 | var midArr = [3, 4];
 13 | var arr = [1, 2, midArr, 5, 6];
 14 | 
 15 | console.log(arr); // [1, 2, Array(2), 5, 6]
 16 | ```
 17 | 
 18 | 우리가 원한건 이게 아니다.
 19 | 
 20 | ## concat의 확장
 21 | 
 22 | 위의 문제를 해결하는게 원래 concat과 같은 메서드다. 다만 concat은 앞뒤를 이어주기만 하지 중간으로 들어갈 수가 없다.
 23 | 
 24 | ```js
 25 | let a = [1, 2, 3];
 26 | let b = ['foo', 'bar'];
 27 | 
 28 | let c = a.concat(b);
 29 | console.log(c); // [1, 2, 3, "foo", "bar"]
 30 | ```
 31 | 
 32 | 단순히 앞뒤를 더해 새로 만드는 것은 concat이 성능적으로 조금 더 좋다. 다만 중간에 추가하는 다음과 같은 경우는 spread를 사용한다.
 33 | 
 34 | ```js
 35 | let a = [1, 2, 3];
 36 | let b = ['foo', 'bar', ...a];
 37 | 
 38 | console.log(b); // ["foo", "bar", 1, 2, 3]
 39 | // let c = [...a, ...b] 이 코드는 그다지 좋지 않다.
 40 | ```
 41 | 
 42 | `...`을 사용하면 기존 `[1,2,3]`의 배열이 `1 2 3`으로 변경된다. 말그대로 spread다.
 43 | 
 44 | 이걸 조금 더 강력하게 사용할 수 있는 점은 중간에 넣을 수도 있다는 것이다.
 45 | 
 46 | ```js
 47 | let a = [1, 2, 3];
 48 | let b = ['foo', ...a, 'bar'];
 49 | 
 50 | console.log(b); // ["foo", 1, 2, 3, "bar"]
 51 | ```
 52 | 
 53 | ## 인자의 배열 대체
 54 | 
 55 | 함수의 인자에 들어가는 배열을 대체할 수 있다.
 56 | 
 57 | 함수호출은 그냥 `함수명()`으로 실행한다. 아래와 같은 상황에서 사용될 수 있다.
 58 | 
 59 | ```js
 60 | let arr = [1, 2, 3, 4, 5];
 61 | let arr2 = [1, 2, 3];
 62 | let sum = (a, b, c, d, e) => a + b + c + d + e;
 63 | 
 64 | let sumArr = sum(...arr);
 65 | let sumArr2 = sum(...arr2, 10, 100);
 66 | 
 67 | console.log(sumArr); // 15
 68 | console.log(sumArr2); // 116
 69 | ```
 70 | 
 71 | ## 배열복사
 72 | 
 73 | 배열 복사는 사실 코딩하다보면 꽤나 많이 쓰이는 기능이다. 기존의 배열에 영향을 주지 않고 어떤 기능을 하기 위해서 많이 쓰인다.
 74 | 
 75 | 그냥 간단하게 사용하면 된다.
 76 | 
 77 | ```js
 78 | let arr = [1, 2, 3, 4];
 79 | let arr2 = [...arr];
 80 | ```
 81 | 
 82 | ## String to Array
 83 | 
 84 | 사실상 구체적으로 보자면 배열복사와 크게 다르진 않지만 쉽게 쓰이는 트릭이다. 흔히들 문자열을 배열로 만드려면 `str.split("")`이렇게 사용하지만 좀 더 명확하게 spread operator를 사용할 수 있다.
 85 | 
 86 | ```js
 87 | let str = 'helloWorld!';
 88 | let strArr = [...str];
 89 | 
 90 | console.log(strArr); //["h", "e", "l", "l", "o", "W", "o", "r", "l", "d", "!"]
 91 | ```
 92 | 
 93 | ## object 복사(할당)
 94 | 
 95 | object는 iterable 객체는 아니지만 값을 할당할 때는 spread operator를 사용할 수 있다. react의 setState에서 사용하는 기술과 동일하다.
 96 | 
 97 | ```js
 98 | let obj1 = {
 99 |   '1': 'a',
100 |   '2': 'b'
101 | };
102 | 
103 | let obj2 = {
104 |   ...obj1,
105 |   '3': 'c'
106 | };
107 | 
108 | console.log(obj2); // { '1': 'a', '2': 'b', '3': 'c' }
109 | ```
110 | 


--------------------------------------------------------------------------------
/Git/gitBy_.git.md:
--------------------------------------------------------------------------------
  1 | # .git으로 이해하는 GIT
  2 | 
  3 | 깃은 분산된 형상관리 툴(DVCS)이다.
  4 | 
  5 | 단순하게만 생각하면 별거 없다. 게임 문명을 하다보면... 다른 문명이 내 원더 대신 만들면 돌려서 다른걸 생산해야 한다.
  6 | 
  7 | 프로젝트도 이처럼 저장과 불러오기가 필요한데 이게 바로 깃이다.
  8 | 
  9 | ## 개념
 10 | 
 11 | 기본 개념은 아래의 그림과 같다.
 12 | 
 13 | ![git life cycle](/assets/images/gitBy_.git_gitlifecycle.png)
 14 | 
 15 | index가 staged, staging area다.
 16 | 
 17 | ## git init
 18 | 
 19 | `init` 명령어는 local repository를 만든다. 이 로컬 저장소는 바로 .git에 들어가있다.
 20 | 
 21 | .git에는 아래와 같은 내용이 초기 세팅된다.
 22 | 
 23 |     config
 24 |     description
 25 |     HEAD
 26 |     hooks/
 27 |     info/
 28 |     objects/
 29 |     refs/
 30 | 
 31 | ## git add
 32 | 
 33 | add 명령은 working directory의 파일을 staging area로 옮긴다.
 34 | 
 35 | 그럼 이 staging area(이하 staged)는 뭘까?
 36 | 
 37 | staged는 .git의 index다. add를 하는 순간 .git에는 인덱스가 생긴다.
 38 | 
 39 | 동시에 objects에는 blob타입의 객체가 생성된다. 이는 파일에 대한 내용이다. 파일 내용을 가지고 hash하여 만들어진다.
 40 | 
 41 | 깃은 모든 파일을 blob 타입의 객체로 관리한다. 그런데 파일의 내용이 기준이기 때문에 파일의 내용이 변경되면 새로운 객체가 생긴다. 파일 두개를 add하면 당연히 두개의 blob객체가 생성되고, 기존의 파일 1개의 내용을 변경하여 add하면 새로운 객체가 생겨 총 3개의 객체가 생성된다.
 42 | 
 43 | 인덱스는 tree형태로 구성되며 객체의 이름과 hash값을 가진다. 그걸 가지고있으니 추적할 수 있게된다.
 44 | 
 45 | ## git commit
 46 | 
 47 | 깃은 커밋이 핵심이다.
 48 | 
 49 | 게임에서 사실 되돌일 일은 많이 없지 않나? 그래서 저장이 제일 중요하다. 이 저장이 커밋이다.
 50 | 
 51 | 커밋을 하면 .git/objects/에는 tree, commit 두 개의 객체가 생긴다.
 52 | 
 53 | commit객체는 tree객체의 hash와 Author, Date, Msg, 부모 커밋의 hash를 가진다.
 54 | 
 55 | tree 객체는 커밋시의 index의 스냅샷을 가진다.
 56 | 
 57 | 그래서 예를들어 push하면 `Compressing objects: 100% (5/5), done.` 이와 비슷한 표준출력이 발생한다. 5개의 객체가 전달되는 것이다.
 58 | 
 59 | ## git status
 60 | 
 61 | 파일을 생성하고 status를 치면 working tree와 index의 blob객체의 내용이 서로 다르다. 그래서 git add 하라고 뜬다.
 62 | 
 63 | add 하고 파일을 변경한 뒤 status를 칠 때도 마찬가지다. index의 blob객체와 내용이 다르면 이거 확인하라고 뭐라뭐라 뜬다.
 64 | 
 65 | add 상태에서 status를 치면 head -> branch -> commit -> tree 객체의 내용과 index를 비교하여 다른게 있는지 알려준다.
 66 | 
 67 | working tree, index, head/branch/commit/tree가 서로 일치하면 클린한 상태가 된다.
 68 | 
 69 | ## git branch
 70 | 
 71 | HEAD는 참조변수다. branch 역시 참조변수다. HEAD는 보통의 경우 branch를 가리킨다. branch는 커밋을 가리킨다.
 72 | 
 73 | checkout은 이 HEAD를 변경하는 명령어이며, reset은 HEAD의 참조값과 branch의 참조값을 모두 변경한다.
 74 | 
 75 | init부터 여기까지의 어려웠던 내용이 바로 아래 그림이다.
 76 | 
 77 | ![git_objects](/assets/images/gitBy_.git_gitobjects.png)
 78 | 
 79 | ## git pull & git fetch
 80 | 
 81 | 위의 그림의 좌측 맨위를 보면 HEAD는 ref/heads/master 를 바라본다. 설명을 위해 master브랜치에서만 작업한다고 가정하자. 로컬에서는 9번 커밋까지만 진행하고 누군가 10번 커밋을 진행해 push했다고 가정하자.
 82 | 
 83 | `fetch` 명령을 같은 master 브랜치로 실행한다면 remote 저장소의 objects, branch등을 로컬 저장소로 가져온다. 그럼 ref/remotes/origin/master 즉 origin/master 브랜치 참조변수는 remote에서 변경된 10번 커밋을 바라볼 것이다.
 84 | 
 85 | | ref/heads/master | ref/remotes/origin/master |
 86 | | ---------------- | ------------------------- |
 87 | | 9번커밋          | 10번커밋                  |
 88 | 
 89 | 이게 현재 상황이다. 같은 master 브랜치지만 remotes와 local이 바라보는 커밋이 다르다.
 90 | 
 91 | 이 때 merge 작업을 진행해 HEAD를 움직여준다.
 92 | 
 93 | `pull` 명령은 remote 저장소의 변경사항을 받아 merge까지 진행한다. HEAD가 변경되고 그에따라 커밋이 바라보는 tree객체가 변경된다. 따라서 tree에 쓰인 파일 정보가 달라 working tree 까지 반영한다.
 94 | 
 95 | ## stash
 96 | 
 97 | 임시저장소다. 작업하다가 master 브랜치의 버그가 발생한 것을 인지 한경우 커밋을 할 순 없으니 stash에 저장한 뒤 master로 이동한다.
 98 | 
 99 | ---
100 | 
101 | ### 참고자료
102 | 
103 | - [git의 원리 (git object를 중심으로)(빨간색코딩)](https://sjh836.tistory.com/37)
104 | - [쩜깃의 이해](https://jusths.tistory.com/64)
105 | 
106 | 두 사이트 모두 정말 큰 도움 됐습니다.
107 | 
108 | - [생활코딩 gistory youtube](https://www.youtube.com/watch?v=QpTzoiiYoV4&list=PLuHgQVnccGMC6_JRFarkLPBfSNFwrGVlJ&index=6&t=0s)
109 | - [pro git](https://git-scm.com/book/ko/v2)
110 | 


--------------------------------------------------------------------------------
/HTML/Head_Meta.md:
--------------------------------------------------------------------------------
 1 | # **Head Meta**
 2 | 
 3 | **HTML** `<meta>` 요소는...
 4 | <br/>
 5 | 
 6 | `<base>, <link>, <script>, <style>` 또는 `<title>`과 같은 다른 메타관련 요소로 나타낼 수 없는 메타데이터를 나타낸다.
 7 | <br/>
 8 | 
 9 | 메타데이터는 **데이터를 설명하는 데이터**이다.
10 | <br/>
11 | 
12 | ## 인코딩 셋팅
13 | 
14 | `<meta charset="utf-8">`
15 | <br/>
16 | 
17 | 이 요소는 문서의 `character incoding` 에 대해서 간단히 표시한다.
18 | 당연히 요즘에는 `utf-8` 을 사용하는게 좋다. 그렇게 대부분이 사용한다.
19 | <br/>
20 | 
21 | ```html
22 | // html5이전
23 | <meta http-equiv="Content-Type" content="text/html; charset=IANAcharset">
24 | ```
25 | 
26 | **Naver와 Google** 역시 `<head>` 최상단에 선언하고 있다.
27 | <br/>
28 | 
29 | 많은 `<meta>` 요소가 `name` 과 `content` 속성을 가진다:
30 | <br/>
31 | 
32 | - `name` 은 메타 요소의 형태를 알려준다. 이것이 어떤 타입의 정보를 가지고 있는지.
33 |   - 이 속성은 문서 레벨의 메타데이터의 이름을 정의한다. `itemprop, http-equiv` 또는 `charset` 속성 중 하나라도 설정이 된 경우에는 설정할 수 없다.
34 |   - `application-name` : 웹 페이지 내에서 실행될 어플리케이션의 이름을 정의한다.
35 |   - `author` : 문서의 작성자를 정의한다.
36 |   - `description` : 페이지의 내용에 대한 짧고 정확한 요약을 담고 있다. Firefox나 오페라와 같은 여러 브라우저에서는 이를 즐겨 찾기 페이지의 기본 설명으로 사용한다.
37 |   - `generator`:페이지를 생성한 소프트웨어의 식별자를 담고 있다.
38 |   - `keywords` : 콤마(`,`)로 구분된 페이지의 내용과 관련된 단어를 담고 있다.
39 |   - `referrer` : 문서에서 전송된 요청에 첨부된 `HTTP` 헤더의 참조자(Referer)를 제어한다.(Naver : 문서의 Origin을 전송)
40 |   - `creator` : 문서를 만든사람을 정의.
41 |   - `googlebot` : `robot`과 비슷하지만 구글봇이 수집한다.
42 |   - `publisher` : 문서 게시자의 이름을 정의.
43 |   - `robots` : 협동 크롤러 또는 `robot`이 페이지와 함께 사용해야하는 동작을 정의.
44 |   - `slurp` : 야후 검색을 위한 크롤러에서 사용
45 |   - `viewport` : 뷰포트의 초기 크기 크기에 대한 힌트를 제공한다. 휴대 기기에서만 사용됨.
46 | 
47 | - `http-equiv` : 이 속성은 속성의 이름(`http-equiv(alent)`)에서 알 수 있듯이, `HTTP` 헤더의 이름을 값으로 가질 수 있다. 이 속성의 값으로 서버나 사용자 에이전트의 작동방식을 변경할 수 있는 지시를 정의할 수 있다. 지시 값은 `content` 속성 안에 정의하는데 다음 중 하나 일 수 있다:
48 |   - `content-security-policy` :  이 값을 이용해 현재 페이지에 대한 컨텐트 정책(content policy)를 정의할 수 있다. 컨텐트 정책은 주로 허용된 `server origins`과 `script endpoints`를 명시함으로써 `cross-site scripting` 공격을 막는 것을 돕는다.
49 |   - `refresh`
50 |     - `content` 속성에 양의 정수 값이 설정된 경우, 페이지가 재로딩될 때까지의 시간(초)을 의미한다.
51 |     - `content` 속성이 양의 정수 값을 가지고 그 값의 뒤에 `;url=` 문자열과 함께 유효한 URL이 설정된 경우, 다른 페이지로 리디렉션될 때까지의 시간(초)을 의미한다.
52 |   - `X-UA-Compatible` : 마이크로소프트는 `X-UA-Compatible` 태그로 웹의 호환성을 지정할 수 있도록 하였다.(익스플로러 버전별 호환성 쿼크 설정)
53 | 
54 | - `content` : 이 속성은 `http-equiv` 또는 `name` 속성 중 어떤 것이 사용되느냐에 따라 해당 속성의 값을 갖는다.
55 | 
56 | ```html
57 | <meta name="author" content="Chris Mills">
58 | <meta name="description" content="The MDN Learning Area aims to provide
59 | complete beginners to the Web with all they need to know to get
60 | started with developing web sites and applications.">
61 | ```
62 | 
63 | ## 특정사이트에 사용하는 메타태그
64 | 
65 | 웹 사이트에서 볼 수있는 기능들은 특정 사이트 (예 : 소셜 네트워킹 사이트)에 사용할 수있는 특정 정보를 제공하도록 설계된 독점 제작물이다.
66 | 
67 | ### Facebook
68 | 
69 | `Open Graph Data` 는 `Facebook`이 웹 사이트에 더 풍부한 메타 데이터를 제공하기 위해 발명한 메타 데이터 프로토콜이다.
70 | 
71 | ```html
72 | <meta property="og:image" content="https://developer.cdn.mozilla.net/static/img/opengraph-logo.dc4e08e2f6af.png">
73 | <meta property="og:description" content="The Mozilla Developer Network (MDN) provides
74 | information about Open Web technologies including HTML, CSS, and APIs for both Web sites
75 | and HTML5 Apps. It also documents Mozilla products, like Firefox OS.">
76 | <meta property="og:title" content="Mozilla Developer Network">
77 | ```
78 | 
79 | ### Twitter
80 | 
81 | ```html
82 | <meta name="twitter:title" content="Mozilla Developer Network">
83 | ```
84 | 
85 | ---
86 | 
87 | #### Reference
88 | 
89 | - [MDN](https://developer.mozilla.org/ko/docs/Learn/HTML/Introduction_to_HTML/The_head_metadata_in_HTML)
90 | - [MDN](https://developer.mozilla.org/ko/docs/Web/HTML/Element/meta)


--------------------------------------------------------------------------------
/HTML/input태그의_value바꾸기(input태그의_dirty flag).md:
--------------------------------------------------------------------------------
 1 | # input태그의 value바꾸기(input태그의 dirty flag)
 2 | 
 3 | `<input>`태그의 내용(value)이 변경되면 `setAttribute()`로 값을 변경하여도 브라우저 화면에 반영되지 않는다.
 4 | 
 5 | ```js
 6 | function test() {
 7 |   inputText.setAttribute("value", "test");
 8 |   console.log("test value: "+inputText.value);
 9 |   console.log("test default: "+inputText.defaultValue);
10 | }
11 | ```
12 | 
13 | ```html
14 | <input type="text" id="inputText" name="testName"> // 만약 텍스트박스에 무언가 입력한다면
15 | <input type="button" value="test" onclick="test()">// 버튼을 눌러도 화면에 변화가 없다.
16 | ```
17 | > [예시(codepen)](https://codepen.io/dae-hwa/pen/gJMwQq)
18 | 
19 | <br/>
20 | 
21 | ## dirty value flag
22 | 
23 | `<input>` element에 **dirty value flag(이하 더티 플래그)** 라는 속성이 있다. boolean 타입이고, **false가 초기값**이다. **value가 변경되면 true**로 바뀐다.
24 | 
25 | value의 속성이 add, set, remove될 때, **더티 플래그의 값이 false인 경우 element의 값이 value값이 된다.** (더티 플래그가 true일 경우 element의 값이 value의 속성 값으로 설정되지 않는다.)
26 | 
27 | value속성을 add, set, remove하는 것은 value의 `default value`프로퍼티를 변경하는 것이다. 즉, 더티 플래그가 **false인 경우 element의 default value의 값이 value 프로퍼티의 값이 된다.**
28 | 
29 | ```js
30 | function test() {
31 |   inputText.setAttribute("value", "test");
32 |   console.log("test value: "+inputText.value);
33 |   console.log("test default: "+inputText.defaultValue);
34 | }
35 | ```
36 | 
37 | ```html
38 | <input type="text" id="inputText" name="testName"> // 만약 텍스트박스에 "무언가"를 입력한다면 
39 |                                                    // inputText의 defaultValue와 value프로퍼티의 값은 "무언가", 
40 |                                                    // dirty value flag는 true로 변하게 된다.
41 | 
42 | <input type="button" value="test" onclick="test()">// 버튼을 클릭하면
43 |                                                    // inputText의 value 프로퍼티의 값은 여전히 "무언가"이지만,
44 |                                                    // default value는 test로 바뀐다.
45 | ```
46 | > [예시(codepen)](https://codepen.io/dae-hwa/pen/RmRzzV)
47 | 
48 | <br/>
49 | 
50 | ## .value
51 | 
52 | 더티 플래그가 true로 바뀌면, attribute를 바꾸는 방식으로 value프로퍼티의 값이 바뀌지 않는다. 이때, value 프로퍼티로 값을 직접 변경 할 수 있다.
53 | 
54 | ```
55 | document.getElementById("id").value="new value";
56 | ```
57 | 
58 | value 프로퍼티는 값을 가져올때(get) element의 현재 값을 반환하고, **새 값으로 설정(set; =연산자 사용)할 경우 더티 플래그가 true로 바뀐다.**
59 | 
60 | ```js
61 | function test() {
62 |   inputText.setAttribute("value", "test");
63 |   console.log("test value: "+inputText.value);
64 |   console.log("test default: "+inputText.defaultValue);
65 | }
66 | ```
67 | 
68 | ```html
69 | <input type="text" id="inputText" name="testName">
70 | // test3 혹은 test4를 누르는 순간부터 dirty value falg는 true가 되고,
71 | // test1, test2를 눌러도 화면에 보이는 inputText의 값이 바뀌지 않는다.
72 | <input type="button" value="test1(setAttribute)" onclick="test1()">
73 | <input type="button" value="test2(setAttribute)" onclick="test2()">
74 | <input type="button" value="test3(.value)" onclick="test3()">
75 | <input type="button" value="test4(.value)" onclick="test4()">
76 | ```
77 | > [예시(codepen)](https://codepen.io/dae-hwa/pen/WBxxKK)
78 | 
79 | <br/>
80 | 
81 | MDN Docs는 `setAttribute()`가 일관성 없이 동작할 수 있기 때문에 프로퍼티를 사용할 것을 권장한다.(e.g.`Element.value`)
82 | 
83 | ---
84 | 
85 | #### Reference
86 | 
87 | - [MDN docs - Element.setAttribute()](https://developer.mozilla.org/en-US/docs/Web/API/Element/setAttribute#Notes)
88 | - [W3C Recommendation,Forms](https://www.w3.org/TR/html5/sec-forms.html#input-dirty-value-flag)
89 | 
90 | 
91 | 


--------------------------------------------------------------------------------
/Java/ArrayList vs LinkedList 그리고 Vector.md:
--------------------------------------------------------------------------------
 1 | # ArrayList vs LinkedList 그리고 Vector
 2 | 
 3 | `ArrayList`와 `LinkedList`는 `JCF(Java Collection Framework)`의 형태로 제공되며 `List` 인터페이스를 상속한다.
 4 | 
 5 | ## ArrayList
 6 | 
 7 | `ArrayList`는 **데이터들이 순서대로 쭉 늘어선 배열의 형식**을 가지고 있으며 요소를 추가하거나 삭제 할 때는 이미 리스트의 크기가 정해져 있어서 **임시 배열을 생성해서 데이터를 복사**하는 방법을 사용한다.
 8 | 
 9 | ![array_list](/assets/images/array_list.png)
10 | 
11 | `ArrayList`는 각 요소의 위치 값 즉, `index`를 가지고 있으므로 **해당 요소의 `index` 값을 통해 값에 접근**할 수 있다.
12 | 
13 | <br/>
14 | 
15 | ## LinkedList
16 | 
17 | `LinkedList`는 각 노드의 앞과 뒤에 있는 **노드의 주솟값으로 연결**되어 있어서 요소를 추가하거나 삭제 할 때는 앞과 뒤쪽 노드의 주솟값만 바꿔주면 된다.
18 | 
19 | ![linked_list](/assets/images/linked_list.png)
20 | 
21 | `LinkedList`는 **앞의 요소부터 차례대로 노드가 참조하고 있는 주소 값을 찾아가야 하므로** 검색이 느리다.
22 | 
23 | <br/>
24 | 
25 | > 즉, 데이터의 삽입, 삭제에 대한 처리가 많으면 `LinkedList`가 성능 상 유리하고 데이터의 검색 즉, 참조 처리가 많으면 `ArrayList`를 사용하는 것이 유리하다.
26 | 
27 | <br/>
28 | 
29 | ## Vector
30 | 
31 | `Vector`의 기본적인 동작은 `ArrayList`와 동일하다. 하지만, 가장 큰 차이점은 동기화 처리에서 나온다.
32 | 
33 | **멀티쓰레드 환경에서 데이터의 동기화 처리는 중요한 부분**이다.<br/> `동기화`는 복수의 쓰레드로부터 데이터의 추가나 삭제가 일어났을 때 내부의 데이터는 안전하게 처리되도록 하는 것이다.
34 | 
35 | `Vector`의 경우 **무조건 동기화**처리를 한다. 즉, 싱글쓰레드 환경에서의 `Vector`는 `ArrayList`나 `LinkedList`보다 성능이 떨어진다.
36 | 
37 | 사실, Java 1.2 버전 이상부터의 `Vector`는 이전 버전과의 호환을 위해서 많이 쓰인다. 동기화 처리가 필요환 환경에서는 `Collection.synchronizedCollection(Collection c)`나 `synchronized List, Map`을 사용하는 것이 성능상 더 유리하다.
38 | 
39 | <br/>
40 | ---
41 | 
42 | #### Reference
43 | 
44 | - [자료구조: Linked List 대 ArrayList](http://www.nextree.co.kr/p6506/)
45 | - [ArrayList와 LinkedList의 차이](https://sung-studynote.tistory.com/49)
46 | - [Java Vector와 ArrayList, LinkedList의 차이점](https://seeit.kr/36)
47 | 
48 | 


--------------------------------------------------------------------------------
/Java/JVM(Java Virtual Machine).md:
--------------------------------------------------------------------------------
 1 | # JVM(Java Virtual Machine)
 2 | 
 3 | <br/>
 4 | 
 5 | ## JVM이란?
 6 | 
 7 | `Java`는 기본적으로 `JVM`위에서 작동된다. `JVM`은 `Java`와 OS(운영체제)사이에 중간 역할을 함으로써, **`Java`애플리케이션이 OS에 관계 없이 작동할 수 있도록 해준다.** 즉, `Java`로 작성된 애플리케이션은 Mac이든 Windows든 Linux든 해당 OS에 적합한 `JVM`을 설치해주면 그 위에서 작동하기 떄문에 어떤 OS든 같은 코드로 동작할 수 있다.
 8 | 
 9 | `JVM`은 **스택 기반의 가상 머신**이며, 메모리 관리와 GC(Garbage Collector)의 역할을 수행한다.
10 | 
11 | <br/>
12 | 
13 | `JVM`은 `Class Loader`, `Execution Engine`, `Runtime Data Areas`로 구성되며 다음과 같은 실행 과정을 거친다.
14 | 
15 | 1. `JVM`은 OS로부터 프로그램을 실행하는데 필요한 메모리를 할당받는다.
16 | 
17 | 2. `Class Loader`를 통해 컴파일된 자바 코드(.class)를 `JVM`으로 로딩한다.
18 | 
19 | 3. `Class Loader`를 통해 로딩된 자바 바이트 코드가 `Runtime Data Areas`로 배치된다.
20 | 
21 | 4. `Runtime Data Areas`에 배치된 바이트코드를 `Execution Engine`에서 해석하고 실행한다.
22 | 
23 | ## Class Loader
24 | 
25 | `JVM`에 **Runtime 시점**에 동적으로 클래스를 로딩한다. OS에서 할당 받은 메모리 `jar`파일 내의 클래스들을 로딩하며 사용하지 않는 클래스는 메모리에서 삭제한다.
26 | 
27 | <br/>
28 | 
29 | ## Runtime Data Areas
30 | 
31 | JVM이 프로그램의 수행을 위해 할당 받은 메모리 공간을 말한다.
32 | 
33 | ![java_Runtime_Data_Areas](/assets/images/java_Runtime_Data_Areas.jpg)
34 | 
35 | <br/>
36 | 
37 | ![java_runtime_data_area](/assets/images/java_runtime_data_area.png)
38 | 
39 | 
40 | <br/>
41 | 
42 | ## Execution Engine
43 | 
44 | 로딩된 클래스 파일들은 `Execution Engine`에 의해서 실행 된다. **`Execution Engine`은 자바 바이트 코드를 해석하고 실행**한다. 그리고 이를 해석하는 방식에는 인터프리터 방식과 JIT(Just In Time)컴파일러에 의한 방식 두 가지가 있다.
45 | 
46 | <br/>
47 | 
48 | ### 인터프리터
49 | 
50 | `JVM`이 처음 나왔을 때는 **자바 바이트 코드를 명령어 단위로(한줄씩) 해석하기 떄문에 느리다**는 단점이 있다.
51 | 
52 | ### JIT(Just In Time)
53 | 
54 | 인터프리터 방식의 단점을 해결하기 위해 JIT 방식이 도입되었다. 한줄씩 해석하여 실행하는 것이 아닌 자바 바이트 코드 전체를 한 번에 컴파일하여 Native코드로 변경하여 실행한다. 변경된 코드는 인터프리터에 의한 해석이 필요 없기 때문에 빨라질 수 있다.<br/> 하지만 이처럼 **컴파일 하는데도 비용이 발생하기 떄문에 `JVM`은 모든 코드를 JIT방식으로 컴파일하지 않고 인터프리터 방식으로 해석하다가 일정 기준이 넘어가면 JIT 방식으로 컴파일하고 실행하는 방식**을 사용하고 있다.
55 | 
56 | <br/>
57 | 
58 | ---
59 | 
60 | #### Reference
61 | 
62 | - [자바가상머신, JVM(Java Virtual Machine)이란 무엇인가?](https://asfirstalways.tistory.com/158)
63 | - [JVM 이란?](https://medium.com/@lazysoul/jvm-%EC%9D%B4%EB%9E%80-c142b01571f2)
64 | 
65 | 


--------------------------------------------------------------------------------
/Java/String, StringBuilder, StringBuffer.md:
--------------------------------------------------------------------------------
 1 | # String, StringBuilder, StringBuffer
 2 | 
 3 | <br/>
 4 | 
 5 | ## String
 6 | 
 7 | `Java`에서 `String`객체의 특성을 알고 있어야 `StringBuilder`와 `StringBuffer`의 차이를 알 수 있다.
 8 | 
 9 | `String`객체는 `char[]`배열로 이뤄져있으며, 기본적으로 `immutable(변경불가능)`하다. <br/>`+`나 `concat` 메서드를 이용해 새로운 문자열을 합치려하면 **기존 `String`객체가 가리키고 있던 문자열을 복사하고 새로운 문자열을 덧붙여 새로운 객체를 반환**한다. 이후 기존 객체는 `GC`에 의해 메모리가 회수된다.
10 | 
11 | 이러한 특성 때문에 `String`객체는 메모리의 낭비로 이어질 수 있다는 단점이 있다. 하지만, `immutable`한 특성 때문에 `thread-safe`하다. 즉, `multi-thread`환경에서 동시에 객체에 접근하더라도 변하지 않기 때문에 동기화를 고려하지 않고 내부적으로 데이터를 공유할 수 있다.
12 | 
13 | <br/>
14 | 
15 | ## StringBuilder vs StringBuffer
16 | 
17 | `StringBuilder` 와 `StringBuffer`는 `mutable(변경 가능)`하다. 문자열을 덧붙이거나 합칠 시 새로운 객체를 반환하지 않고 기존 객체의 버퍼 크기를 늘리며 문자열을 추가한다.
18 | 
19 | 단, 이 두 가지의 차이점은 `multi-thread`환경에서의 **동기화 문제에 대한 처리**에서 나온다.
20 | 
21 | <br/>
22 | 
23 | ### StringBuilder
24 | 
25 | ---
26 | 
27 | `StringBuilder`는 `String`에서 `+`나 `concat`메서드를 통한 연산이 많은 경우 사용하는것이 좋다. 단, **동기화에 대한 처리를 하지 않는다.** 따라서 `StringBuffer`에 비해 성능 면에서 좋고, `multi-thread`환경이 아니라면 `StringBuilder`을 사용하는 것이 좋다.
28 | 
29 | 사실, `jdk1.5`이후 부터 `String`객체는 컴파일 타임에 `StringBuilder`로 변경된다. 즉, `String` 클래스를 이용하여 객체를 생성하더라도 `StringBuilder`로 컴파일되어 동작하기 때문에 `jdk1.5`이후부터는 `StringBuilder`를 사용할 이유가 없어졌다.
30 | 
31 | 
32 | ### StringBuffer
33 | 
34 | ---
35 | 
36 | `StringBuffer`는 내부적으로 모든 메소드에 대해 `synchronized` 키워드가 붙어있다. 즉, **동기화 처리를 하고 있고 이 덕분에 `StringBuilder`와 비교해서 `thread-safe`하다.**
37 | 
38 | 하지만, `multi-thread`환경이 아닐 때 사용한다면 `StringBuilder`에 비해 **성능 면에서 떨어질 수 있기 때문에 이 점을 고려하여 사용**해야 한다.
39 | 
40 | > `Java`의 `synchronized` 키워드는  쉽게 생각하면 **multi-thread로 동시접근되는것을 막는다** 라고 볼 수 있다. <br/>
41 | > 예를 들어, **함수에 synchronized를 걸면 그 함수가 포함된 해당 객체에 lock을 건다**라고 볼 수 있다.
42 | 
43 | <br/>
44 | 
45 | ---
46 | 
47 | #### Reference
48 | 
49 | - [자바가상머신, JVM(Java Virtual Machine)이란 무엇인가?](https://asfirstalways.tistory.com/158)
50 | - [JAVA String, StringBuffer, StringBuilder 차이점](https://jeong-pro.tistory.com/85)
51 | 
52 | 


--------------------------------------------------------------------------------
/Java/WAS.md:
--------------------------------------------------------------------------------
  1 | # WAS(Web Application Server)
  2 | 
  3 | ## 웹 서버(Web Server)
  4 | 
  5 | 클라이언트가 요청한 문서나 자원을 전달하는 역할을 한다.
  6 | 
  7 | 클라이언트는 서버에게 서비스를 요청한다.
  8 | 
  9 | 서버는 서비스 제공한다.
 10 | 
 11 | ![tier1](../assets/images/was1.png)
 12 | 
 13 | <br/>
 14 | 
 15 | ## 2-Tier Architecture
 16 | 
 17 | ![tier2](../assets/images/was2.png)
 18 | 
 19 | ### DBMS(Data Base Management System)
 20 | 
 21 | DBMS등장 이전에는 데이터를 저장하고 불러오는것을 직접 구현 해야했다. 하지만, 데이터가 많아지며 별도의 관리가 필요해졌고 DBMS가 등장하였다. 
 22 | 
 23 | <br/>
 24 | 
 25 | DMBS는 보통 서버 형태로 서비스를 제공한다. 따라서 DBMS에 직접 접속해서 동작하는 클라이언트 프로그램이 만들어졌다.
 26 | 
 27 | 이러한 방식은 클라이언트의 로직이 많아지고, 클라이언트 프로그램의 크기가 커지며, 로직이 변경되면 클라이언트가 새로 배포되어야 한다.
 28 | 
 29 | 또한, 로직이 클라이언트에 포함되어 배포되기 때문에 보안이 나쁘다.
 30 | 
 31 | <br/>
 32 | 
 33 | ### CGI(Common Gateway Interface)
 34 | 
 35 | 초기 웹은 정적 데이터만 보여줬다. 웹 서버 본연의 기능은 미리 준비된 정보(정적 리소스)를 클라이언트의 요청에 따라 응답해주는 것이기 때문이다.
 36 | 
 37 | 웹이 발전하며 동적인 기능을 요구하기 시작했다. 지금은 너무 당연하지만, 웹에서 데이터를 입력하고 조회하는 것 또한 동적인 기능이다.
 38 | 
 39 | 당연히, 이러한 기능들은 별도의 프로그래밍을 통해 구현해야 한다. 이를 위해 웹 서버에서 프로그래밍 기능이 들어가는 방식을 CGI라고 한다.
 40 | 
 41 | > 서버 프로그램 내부의 프로그램에서 처리한 결과를 클라이언트에 응답하도록 서버와 내부 프로그램을 이어주는 방법 혹은 규칙이 CGI이다.
 42 | 
 43 | <br/>
 44 | 
 45 | 단순한 프로그래밍에서는 문제가 없었다. 하지만, 프로그램이 복잡해지고 DBMS와 연계되는 작업이 많아지면서 사용자가 증가할수록 성능이 떨어지는 문제가 발생했다.
 46 | 
 47 | <br/>
 48 | 
 49 | ## 3-Tier Architecture
 50 | 
 51 | ![tier3](../assets/images/was3.png)
 52 | 
 53 | ### 미들웨어(MiddleWare)
 54 | 
 55 | 2-Tier Architecture의 단점으로 미들웨어가 등장하게 되었다. 클라이언트와 데이터베이스 서버 사이에 다른 서버를 두는 방식이다.
 56 | 
 57 | 클라이언트는 요청만 보내고, 미들웨어에서 로직을 수행한다. 만약, 데이터 조작이 필요하면 미들웨어가 DBMS에 작업을 맡기고 그 결과를 클라이언트에게 전달한다.
 58 | 
 59 | 클라이언트는 응답을 받아서 출력만 하면되고, 미들웨어에 요청만 보내면 되기 때문에 프로그램의 크기가 줄어든다. 또한, 로직이 바뀌어도 다시 배포할 필요 없이 미들웨어만 수정하면 된다.
 60 | 
 61 | <br/>
 62 | 
 63 | ## WAS(Web Application Server)
 64 | 
 65 | 넓은 의미에서 미들웨어라고 할 수 있다.
 66 | 
 67 | 웹 클라이언트의 요청 중 웹 애플리케이션이 동작하도록 지원하는 목적을 가진다.
 68 | 
 69 | <br/>
 70 | 
 71 | ### 기능
 72 | 
 73 | - 프로그램 실행환경과 데이터 베이스 접속 기능을 제공한다.
 74 | - 여러 개의 트랜젝션을 관리한다.
 75 | - 업무 처리 비즈니스 로직을 수행한다.
 76 | 
 77 | <br/>
 78 | 
 79 | 이외에도 웹 서버의 기능도 기본적으로 제공한다(톰캣만 설치해도 별도의 웹 서버가 필요 없는 이유이다).  하지만, 초창기의 WAS는 내장 웹서버의 성능이 좋지 않았다. 따라서 아파치 서버와 톰캣 서버를 함께 실행을 해서 사용하는 경우가 많았다. 하지만, 현재는 WAS에 내장되어 있는 웹 서버의 성능이 많이 개선되어 톰캣만으로도 충분히 동작하는 경우가 많아졌다.
 80 | 
 81 | 하지만, 그럼에도 큰 규모의 프로젝트에서는 웹 서버에서 정적인 컨텐츠를 웹 브라우저로 전송하고, WAS는 동적인 결과를 전송하는 역할을 하도록 나눈다.
 82 | 
 83 | ![tier4](../assets/images/was4.png)
 84 | 
 85 | ### WAS와 웹 서버를 나누는 이유
 86 | 
 87 | - 자원 이용의 효율성
 88 |     - 웹 서버는 보다 간단하게 만들어졌다. 따라서, 정적인 동작은 웹 서버에서 하는 것이 더 효율적이다.
 89 | - 장애 극복(failvoer)
 90 |     - WAS에서 동작하도록 만든 프로그램이 오작동하여 WAS자체에 문제가 발생할 수 있다. 따라서 WAS를 재시작 해야 하는 경우가 생길 수 있다. 만약 WAS 서버가 여러개 있다면, 문제가 발생한 WAS에 웹 서버에서 클라이언트가 접근 하지 못하게 한 뒤  WAS의 문제를 처리할 수 있다. 따라서, 무중단으로 서비스를 운영할 수 있다.
 91 |         > 참고 - [로드밸런싱과 클러스터링](https://github.com/Im-D/Dev-Docs/blob/master/Network/%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%8B%B1%20&%20%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0%EB%A7%81.md)
 92 | - 배포 및 유지 보수의 편의성
 93 | 
 94 | <br/>
 95 | 
 96 | ---
 97 | 
 98 | #### References
 99 | 
100 | - [WAS - 부스트코스](https://www.edwith.org/boostcourse-web/lecture/16666/)
101 | - [CGI - 정보통신기술용어해설](http://www.ktword.co.kr/word/abbr_view.php?m_temp1=651&m_search=cgi)
102 | - [common gateway interface (CGI)](https://whatis.techtarget.com/definition/common-gateway-interface-CGI)
103 | - [What is Difference Between Two-Tier and Three-Tier Architecture?](http://www.softwaretestingclass.com/what-is-difference-between-two-tier-and-three-tier-architecture/)
104 | 


--------------------------------------------------------------------------------
/Javascript/Control_CSSOM.md:
--------------------------------------------------------------------------------
  1 | # Control CSSOM
  2 | 
  3 | `CSSOM(CSS Object Model)` . 즉, 자바스크립트로 `CSS`를 조작할 수 있도록 하는 `API`이다.
  4 | <br/>
  5 | 
  6 | 위에 관련된 자세한 내용은 웹의 렌더링과정에 대한 내용을 보면 이해하는데 도움이 될 것으로 생각이 된다.
  7 | <br/>
  8 | 
  9 | > [MDN에서도 잘 설명이 되어있다.](https://developer.mozilla.org/ko/docs/Web/API/CSS_Object_Model)
 10 | 
 11 | 그렇다면 우리는 어떻게 사용하고 있을까?
 12 | <br/>
 13 | 
 14 | ## Element.style
 15 | 
 16 | 우리가 많이 사용하는 방법이다.
 17 | 일반적으로 개발자들이 자바스크립트로 `CSS`를 변경하려고 할 때 많이 사용하는 방법 중 하나이다.(Jquery를 사용안한다는 전제)
 18 | <br/>
 19 | 
 20 | ```js
 21 | document.body.style.backgroundColor = 'black';
 22 | document.body.style.padding = '100px';
 23 | ```
 24 | 
 25 | 위와같이 하게 되면서 스타일이 변하면서 `inline` 스타일로 들어가게 된다.
 26 | 또한 `width`나 `height`의 경우는 초기에 입력한 값과 실제로 렌더링된 값이 다를 수 있는 경우가 생기게 된다.
 27 | <br/>
 28 | 
 29 | 그렇다면 실제로 렌더링 결과의 값을 가져올 방법이 없는 것일까?
 30 | <br/>
 31 | 
 32 | 이럴때 사용하는 것이 `CSSOM` 이다. 화면이 렌더링되면서 `DOM TREE` 를 그리고 `CSSOM` 를 그리고 `렌더링트리` 가 만들어지는데 이 과정에서의 결과값이 `CSSOM`에 들어가게 된다. 
 33 | <br/>
 34 | 
 35 | 결론적으로 `CSSOM` 안에 있는 `style` 을 가져오게 되면 실제 우리가 보는 화면의 스타일을 알 수 있다는 것이다.
 36 | <br/>
 37 | 
 38 | ## 계산된(computed) 스타일 가져오기
 39 | 
 40 | `API` 적으로 지원을 해주고 있어서 쉽게 가져와서 읽을 수 있다. 
 41 | 
 42 | ```js
 43 | window.getComputedStyle(document.body) // 너무 많은 정보를 보여준다.
 44 | ```
 45 | 
 46 | 위와 같이 콘솔에 찍어보면 엄청난 정보가 쏟아진다. 내가 입력했던 정보뿐만 아니라 `Default`값들도 보여주기 때문이다.
 47 | 
 48 | ```js
 49 | window.getComputedStyle(document.body).font; 
 50 | window.getComputedStyle(document.body).color; 
 51 | ```
 52 | 
 53 | 이제 위와 같이 입력을 하게 되면 내가 필요한 정보만을 얻을 수 있게 된다.
 54 | <br/>
 55 | 
 56 | 또한 위에서 언급했듯이 실제 계산된 값을 보여주기 때문에 `width`와 `height`의 값이 숫자로 보여주게 되는 것이다.
 57 | <br/>
 58 | 
 59 | ### 속성을 가져오는 여러가지 방법
 60 | 
 61 | ```js
 62 | // 점(.) 이용, camel case를 사용한다. 
 63 | window.getComputedStyle(el).backgroundColor; 
 64 | 
 65 | // [대괄호] 이용, - 사용 : lint 에서 권고하지 않음. 
 66 | window.getComputedStyle(el)['background-color']; 
 67 | 
 68 | // getPropertyValue() 메소드를 이용, - 사용 
 69 | window.getComputedStyle(el).getPropertyValue('background-color');
 70 | ```
 71 | 
 72 | <br/>
 73 | 
 74 | ## 가상 요소(pseudo-element)에 접근
 75 | 
 76 | `window.getComputedStyle`의 두번째 인자를 전달하면 가상요소의 속성에 접근이 가능하다.
 77 | 
 78 | ```css
 79 | .box::before { 
 80 |     display: block; 
 81 |     width: 50px; 
 82 |     content: 'Example'; 
 83 | }
 84 | ```
 85 | 
 86 | ```js
 87 | let box = document.querySelector('.box'); 
 88 | window.getComputedStyle(box, '::before').width; // '50px'
 89 | ```
 90 | 
 91 | <br/>
 92 | 
 93 | ## 사용할 수 있는 API
 94 | 
 95 | - setProperty() : 설정, 2개의 인자 (속성,값)
 96 | - getProperty() : 가져오기, 1개의 인자
 97 | - item() : 가져오려는 속성의 인덱스를 인자로 사용
 98 | - removeProperty() : 삭제
 99 | 
100 | ```js
101 | // 설정(set) 
102 | document.body.style.setProperty('color', 'lime'); document.body.style.setProperty('font-size', '16px'); // - 를 사용한것에 주목! 
103 | // 읽기(get) 
104 | document.body.style.getPropertyValue('color'); // 'lime' 
105 | 
106 | // item() 이용, 인자값은 인덱스 숫자 
107 | document.body.style.item(0) // 'color' 
108 | document.body.style.item(1) // 'font-size' 
109 | 
110 | // 제거(remove), 제거 후에는 빈 문자열을 반환한다. 
111 | document.body.style.removeProperty('color') // 'lime' 
112 | document.body.style.item(1) // '' 
113 | ```
114 | 
115 | <br/>
116 | 
117 | ---
118 | 
119 | #### Reference
120 | 
121 | - [Javascript로 CSS 제어하기](http://ibrahimovic.tistory.com/56)


--------------------------------------------------------------------------------
/Javascript/DocumentFragment.md:
--------------------------------------------------------------------------------
  1 | # DocumentFragment
  2 | 
  3 | <br/>
  4 | 
  5 | ## repaint와 reflow
  6 | 
  7 | 브라우저는 생성된 DOM 노드의 레이아웃이 변경될 때, 모든 노드를 다시 계산하고 렌더 트리를 재생성한다.
  8 | 이러한 과정을 `reflow`라 하고 `reflow`가 일어난 후, `repaint`가 일어난다.
  9 | 
 10 | 즉, **DOM의 노드가 변경될 때 마다 DOM tree라는 자료구조에 접근**해야 하기 때문에 DOM의 레이아웃을 변경하는 코드를 작성할 때는 이를 최적화하기 위한 고민이 필요하다.
 11 | 
 12 | ### reflow
 13 | 
 14 | ---
 15 | 
 16 | ```js
 17 | function reFlow() {
 18 |     var container = document.getElementById('container');
 19 | 
 20 |     container.appendChild(document.createTextNode('hello'));
 21 | }
 22 | ```
 23 | 
 24 | 위의 코드를 보면 `conatiner`라는 엘리먼트에 `hello`라는 `TextNode`를 추가했다. 이로 인해 DOM 노드의 레이아웃이 바뀌며 `reflow`와 `repaint`가 일어날 것이다.
 25 | 
 26 | ### repaint
 27 | 
 28 | ---
 29 | 
 30 | ```js
 31 | function repaint() {
 32 |     var container = document.getElementById('container');
 33 | 
 34 |     container.style.backgroundColor = 'black';
 35 |     container.style.color = 'white';
 36 | }
 37 | ```
 38 | 
 39 | 위의 코드에서는 이전의 코드와 다르게 엘리먼트의 `style`만 변경했다. 이러한 경우 DOM 노드의 레이아웃은 변경되지 않았고 `style`속성만 변경되었기 때문에 `reflow`는 일어나지 않고 `repaint`만 일어나게 된다.
 40 | 
 41 | `reflow`와 `repaint`가 많아질수록 애플리케이션의 렌더링 성능은 느려지게 되기 때문에 이를 줄일수록 성능을 높일 수 있다.
 42 | 
 43 | 이에 대한 구체적인 설명은 [Repaint와 Reflow](https://github.com/Im-D/Dev-Docs/blob/master/Performance/Repaint%EC%99%80%20Reflow.md)를 참고하면 된다.
 44 | 
 45 | <br/>
 46 | 
 47 | ## Why DocumentFragment?
 48 | 
 49 | `DocumentFragment`를 활용하는 것은 `reflow`를 줄이기 위한 방법 중 하나다.
 50 | 
 51 | ```html
 52 | <body>
 53 | 	<select id="timer">
 54 |     </select>
 55 | </body>
 56 | ```
 57 | 
 58 | ```js
 59 | function addElements() {
 60 |     var target = document.getElementById('timer');
 61 |  
 62 |     for (var i = 0; i < 24; i++) {
 63 |         var option = document.createElement('option');
 64 |  
 65 |         option.innerText = i;
 66 |         target.appendChild(option);
 67 |     }
 68 | }
 69 | ```
 70 | 
 71 | 위 코드는 0시부터 23시까지의 `option`엘리먼트를 셀렉트 박스에 추가하는 예제이다.
 72 | 
 73 | `timer`셀렉트박스에 0부터 23까지 반복을 돌려 매번 셀렉트 박스에 엘리먼트를 추가하고 있다. 24번의 DOM 레이아웃 변경이 일어나게 되기 때문에 24번의 `reflow`와 `repaint`가 각각 일어나게 된다.
 74 | 
 75 | `DocumentFragment`를 활용했을 때의 가장 큰 차이는 `DocumentFragment`객체는 활성화된 DOM트리의 일부가 아니기 때문에 `DocumentFragment`객체에서 일어나는 변경사항은 DOM에 영향을 주지 않는다. 즉, `reflow`를 일으키지 않으며 성능에 큰 영향을 미치지 않게 된다.
 76 | 
 77 | ```js
 78 | function addElements() {
 79 |     var target = document.getElementById('timer');
 80 |     var docFrag = document.createDocumentFragment();
 81 |     for (var i = 0; i < 24; i++) {
 82 |         var option = document.createElement('option');
 83 |  
 84 |         option.innerText = i;
 85 |         docFrag.appendChild(option);
 86 |     }
 87 | 
 88 |     target.appendChild(docFrag.cloneNode(true));
 89 | }
 90 | ```
 91 | 
 92 | 위의 코드를 보면 DOM레이아웃을 변경시키는 경우는 `timer`셀렉트 박스 엘리먼트에 추가할 때 발생한다. 즉, `DocumentFragMent`객체를 셀렉트 박스 엘리먼트에 추가할 때 1번만 DOM 레이아웃이 변경된다. 따라서 각각 24번의 `reflow`와 `repaint`가 일어나던 것을 1번씩만 일어나도록 줄일 수 있게 된다.
 93 | 
 94 | 최신 브라우저의 경우에는 `reflow`가 발생하지 않도록 엔진을 최적화하기 때문에 `DocumentFragment`를 통한 성능 향상을 체감할 수 없는 경우가 많다. 그러나 DOM 객체에 대한 다수의 접근을 필요로하는 작업을 수행해야 하는 상황에서는 충분한 성능 향상을 체감할 수 있다.
 95 | 
 96 | ---
 97 | 
 98 | #### Reference
 99 | 
100 | - [MDN Docs - Document​Fragment](https://developer.mozilla.org/ko/docs/Web/API/DocumentFragment)
101 | - [DocumentFragment를 이용한 JavaScript 성능 최적화](https://untitledtblog.tistory.com/44)
102 | - [Repaint와 Reflow](https://github.com/Im-D/Dev-Docs/blob/master/Performance/Repaint%EC%99%80%20Reflow.md)


--------------------------------------------------------------------------------
/Javascript/MouseEvent.md:
--------------------------------------------------------------------------------
  1 | # Mouse Event
  2 | 
  3 | 오늘은 약간 심플하면서도 약간 헷갈릴만한 주제로 해보려고한다.
  4 | <br/>
  5 | 
  6 | 바로 `Mouse Event`
  7 | <br/>
  8 | 
  9 | 오늘 작업을 하다보니 내가 평소에 알고 있던 마우스 이벤트들인데 왜 이렇게 어렵지라고 생각되는 것이 있어서 정리를 하면서 다시 학습해보려고 한다.
 10 | <br/>
 11 | 
 12 | 기본적으로 내가 알고 있는 마우스 이벤트는 4가지였다.
 13 | <br/>
 14 | 
 15 | - mousedown : 마우스 누른 상태
 16 | - mousemove : 해당 Element 위에서 움직이는 상태
 17 | - mouseup : 마우스 떼는 상태
 18 | - click : mousedown와 mouseup이 한번 일어난 상태
 19 | 
 20 | 위의 4가지의 상태는 우리가 흔히 사용하는 마우스 이벤트이다. 그리고 지금 어디선가 누군가도 이것을 사용하고 있을 것이다.
 21 | <br/>
 22 | 
 23 | 간단한 예제를 만들어 보자면
 24 | <br/>
 25 | 
 26 | ```html
 27 | <html>
 28 |     <head></head>
 29 |     <body>
 30 |         <div style="
 31 |             width:  100px;
 32 |             height:  100px;
 33 |             background-color: black;
 34 |         ">
 35 |         black
 36 |         </div>
 37 |     </body>
 38 | </html>
 39 | ```
 40 | 
 41 | 간단한 검은색 Div를 만들어서 이 Element에 이벤트를 입힌다.
 42 | 
 43 | ```js
 44 | var div = document.getElementsByTagName("div")
 45 | 
 46 | // MouseDown
 47 | div[0].addEventListener("mousedown", function(){
 48 |     console.log("mousedown")
 49 | })
 50 | 
 51 | // MouseMove
 52 | div[0].addEventListener("mousemove", function(){
 53 |     console.log("mousemove")
 54 | })
 55 | 
 56 | // MouseUp
 57 | div[0].addEventListener("mouseup", function(){
 58 |     console.log("mouseup")
 59 | })
 60 | 
 61 | // Click
 62 | div[0].addEventListener("click", function(){
 63 |     console.log("click")
 64 | })
 65 | ```
 66 | 
 67 | 예제를 만들어보고 한번 움직이고, 클릭하고 해보자 그러면 더욱 이해가 잘 될 것이다.
 68 | 
 69 | 자 이제 제일 기본이 되는 이벤트를 알아 보았다. 이제는 헷갈렸던 작업으로 가보자
 70 | <br/>
 71 | 
 72 | ## MouseOver MouseOut
 73 | 
 74 | 알고는 있었지만 추가적으로 알았다고 하자.
 75 | 
 76 | - mouseover : 마우스를 `Element` 위에 올린 상태
 77 | - mouseout : 마우스를 `Element` 위에 올린 상태에서 벗어난 상태
 78 | 
 79 | 쉽게 보자면 내가 이벤트를 선언한 `Element` 위에 마우스를 위치하나 빼냐에 대한 이벤트이다.
 80 | <br/>
 81 | 
 82 | 이번에는 다른 이벤트를 보자
 83 | <br/>
 84 | 
 85 | ## MouseEnter MouseLeave
 86 | 
 87 | - mouseleave : 마우스를 `Element` 위에 올린 상태
 88 | - mouseenter : 마우스를 `Element` 위에 올린 상태에서 벗어난 상태
 89 | 
 90 | 이상하다. 위에서의 2개의 이벤트 아래의 이벤트들과 똑같은데? 왜 때문에 같은 기능을 가진 이벤트가 2개씩 있는 것일까?
 91 | <br/>
 92 | 
 93 | > 이거 때문에 한동안 헤맸다.
 94 | 
 95 | ## MouseOver MouseOut VS MouseEnter MouseLeave
 96 | 
 97 | 2종류의 이벤트는 같은 기능을 하는 것처럼 보이지만 약간의 다른 차이점이 존재한다.
 98 | <br/>
 99 | 
100 | 먼저 예제를 보자 => [예제보기](https://codepen.io/seonhyungjo/pen/wRwWXO)
101 | <br/>
102 | 
103 | 2겹의 `Div` 가 존재한다. 그리고 `Outer div` 에 각각 `MouseOver` 와 `MouseEnter` 이벤트를 추가했다. 그리고 `Inner Div` 에는 이벤트를 추가하지 않았다.
104 | <br/>
105 | 
106 | 결과는 신기하게도 `MouseOver` 이벤트는 자식 `Element`까지 이벤트가 적용이 되었다.
107 | <br/>
108 | 
109 | 결과적으로 `MouseOver MouseOut` 이벤트들은 `Bubble`과 `Capture` 일어나며 다르게 `MouseEnter MouseLeave` 이벤트들은 전파가 되지 않고 선언한 곳에서만 일어나는 것을 확인할 수 있다.
110 | <br/>
111 | 
112 | 관련글을 읽는 것도 도움이 된다. [Event Delegation](https://github.com/SeonHyungJo/FrontEnd-Dev/blob/master/Javascript/Event%20Delegation.md)
113 | <br/>
114 | 
115 | 이 사실은 너무나도 중요하다. 내가 원하는 위치에 `MouseOver` 이벤트를 먹였는데 이상하게 내가 선언하지 않은 곳의 위치에서 작동이 일어나고 있다는 것이 아닌가? 
116 | <br/>
117 | 
118 | 이것은 정말 크리티컬한 이슈가 될 수 있는 것이다.
119 | <br/>
120 | 
121 | 그렇다면 이것을 해결할 수 있는 방법이 있지 않을까?
122 | 당연하게 있다. 그리고 사람들은 이미 알고 있다. 
123 | <br/>
124 | 
125 | ---
126 | 
127 | #### Reference 
128 | 
129 | - http://webclub.tistory.com/116
130 | - http://webclub.tistory.com/456
131 | - [MDN - MouseEnter](https://developer.mozilla.org/en-US/docs/Web/Events/mouseenter)
132 | - [MDN - preventDefault](https://developer.mozilla.org/ko/docs/Web/API/Event/preventDefault)
133 | - [MDN - stopPropagation](https://developer.mozilla.org/ko/docs/Web/API/Event/stopPropagation)


--------------------------------------------------------------------------------
/Javascript/Optional_Chaining.md:
--------------------------------------------------------------------------------
  1 | # Optional Chaining
  2 | 
  3 | ## 소개
  4 | 
  5 | 이 내용은 아직 공식 스펙으로 채택하지 않았다. 다만 추후 추가될만한 소지가 있으며 충분히 매력적이므로 소개해본다.
  6 | 
  7 | 조건적으로 체이닝을 할 수 있다. 이게 무슨 소릴까? 무슨 조건을 이야기 하는 것일까?
  8 | 
  9 | 바로 undefined나 null의 경우 선택적으로 체이닝 할 수 있게하는 문법이다. javascript 뿐만아니라 C#, Swift, CoffeeScript 에서도 지원하는 문법이다.
 10 | 
 11 | ## 기존의 방식
 12 | 
 13 | ```js
 14 | var person = {
 15 |   name: {}
 16 | };
 17 | var certif = person.spec.certification;
 18 | console.log(certif); // Cannot read property 'certification' of undefined
 19 | ```
 20 | 
 21 | 이런 에러를 받아보는 경우가 상당하다. 보통 object 형식에서 데이터를 받아 온 뒤 그 데이터를 사용해야하는 경우인데, 아직 받아오지 않은 상태에서 작업을 해야하는 경우다.
 22 | 
 23 | 그래서 보통은 몇 가지 방법으로 방어적인 코드를 사용한다.
 24 | 
 25 | ```js
 26 | var person = {
 27 |   name: 'tom'
 28 | };
 29 | 
 30 | var certif = '';
 31 | 
 32 | // 1번
 33 | if (person.hasOwnProperty('spec')) {
 34 |   certif = person.spec.certification;
 35 | }
 36 | 
 37 | // 2번
 38 | if (!!person.spec) {
 39 |   certif = person.spec.certification;
 40 | }
 41 | 
 42 | // 3번
 43 | try {
 44 |   certif = person.spec.certification;
 45 | } catch (e) {
 46 |   certif = '';
 47 | }
 48 | console.log(certif); // ''
 49 | ```
 50 | 
 51 | 나는 개인적으로 3가지 방식 모두 자주 사용하고 있었다.
 52 | 
 53 | 혹은 `user.name && user.name.lastName` 처럼 null을 체크하는 방식들도 자주 보인다.
 54 | 
 55 | 그런데 이러한 방식들은 코드의 가독성을 해친다. 또한 자료구조가 조금 복잡해진다면 엄청나게 중요한 코드가 아님에도 생산성이 저하될 수 있다.
 56 | 
 57 | ## 새로운 방식
 58 | 
 59 | 방법은 매우 너무나도 간단하다.
 60 | 
 61 | ```js
 62 | var person = {
 63 |   name: {}
 64 | };
 65 | var certif = person?.spec?.certification;
 66 | console.log(certif);
 67 | ```
 68 | 
 69 | . 앞에 ? 를 추가해주면 끝이다.
 70 | 
 71 | null이나 undefined가 아니라면 그냥 실행하는 방식이다.
 72 | 
 73 | ```js
 74 | const obj = {
 75 |   foo: {
 76 |     bar: {
 77 |       baz: 100
 78 |     }
 79 |   }
 80 | };
 81 | 
 82 | const baz = obj?.foo?.bar?.baz; // 100
 83 | const baz = obj && obj.foo && obj.foo.bar && obj.foo.bar.baz;
 84 | ```
 85 | 
 86 | 이는 babel 공식문서의 소개글의 예시다. 충분히 더 복잡한 자료구조와 씨름할 수 있는 상황이 많다. 따라서 이 문법을 사용한다면 얼마나 편한지 안보고도 알 수 있을 것 같다.
 87 | 
 88 | ## 한계
 89 | 
 90 | 현재 babel의 Stage 1에 머물러 있다.
 91 | 
 92 | - optional construction: new a?.()
 93 | - optional template literal: a?.`{b}`
 94 | - constructor or template literals in/after an Optional Chain: new a?.b(), a?.b`{c}`
 95 | - optional property assignment: a?.b = c
 96 | 
 97 | 이러한 이유들 때문이다. 사용 케이스가 있긴 하지만 아직 불안정하기 때문에 지원하지 않는다고 한다.
 98 | 
 99 | ---
100 | 
101 | ### 참고자료
102 | 
103 | - [Optional Chaining for JavaScript](https://github.com/tc39/proposal-optional-chaining)
104 | - [@babel/plugin-proposal-optional-chaining](https://babeljs.io/docs/en/next/babel-plugin-proposal-optional-chaining.html)
105 | - [Javascript Optional Chaining](https://dev-momo.tistory.com/entry/Javascript-Optional-Chaining)
106 | - [Optional Chaining Operator in JavaScript](https://www.youtube.com/watch?v=FKRVqtP8o48)
107 | - [9 Tricks for Kickass JavaScript Developers in 2019](https://levelup.gitconnected.com/9-tricks-for-kickass-javascript-developers-in-2019-eb01dd3def2a?gi=4624a912a47f)
108 | 


--------------------------------------------------------------------------------
/Javascript/PromisePattern.md:
--------------------------------------------------------------------------------
 1 | # 프로미스 패턴
 2 | 
 3 | 두개 이상의 프로미스를 사용한 비동기 흐름을 제어할 때 사용한다. 예를들어 a 와 b 라는 비동기 작업이 모두 완료되면 c 라는 비동기 작업을 진행해야 한다고 하면 이 경우 어떻게 해야할까를 정의한 것이 프로미스 패턴이다.
 4 | 
 5 | ## All 과 Race
 6 | 
 7 | ### Promise.all([])
 8 | 
 9 | ---
10 | 
11 | 관문패턴이다. 프로세스를 모두 나중으로 미뤄 모두 준비가 되면 시작한다.
12 | 
13 | ```js
14 | // request는 promise 패턴의 비동기 사용자 정의 함수라고 가정
15 | var p1 = request('https://');
16 | var p2 = request('https://');
17 | 
18 | Promise.all([p1, p2])
19 |   .then(function(value) {
20 |     return request('http://');
21 |   })
22 |   .then(function(msg) {
23 |     console.log(msg);
24 |   });
25 | ```
26 | 
27 | 이 배열 안의 값은 promise, thenable, 즉시값 모두 가능하다. 현재는 비동기 처리 후 프로미스가 들어간다. 다만 어떠한 값이 들어가도 상관없다. 그 이유는 Promise.resolve()로 정규화를 하기 때문이다.
28 | 
29 | 여기서 중요한 점은 배열안의 값이 버림처리되면(reject) 모든 결과가 무효처리 되어 버린다. 그렇기 때문에 꼭 에러 처리기를 붙이도록 하자.
30 | 
31 | ### Promise.race([])
32 | 
33 | ---
34 | 
35 | 걸쇠 혹은 경합이라고 불리는 패턴이다. 먼저 온 것만 실행된다. 배열 안의 값은 어떤것이 들어가도 상관없다. 즉시값이 들어가도 되지만 즉시값은 순서가 1 순위라 의미가 없다.
36 | 
37 | 사용법은 all 과 동일하다.
38 | 
39 | ### 타임아웃 경합
40 | 
41 | ---
42 | 
43 | 경합 패턴을 사용하면 타임아웃 패턴을 구현할 수 있다.
44 | 
45 | ```js
46 | function timeoutPromise(time) {
47 |   return new Promise(function(resolve, reject) {
48 |     setTimeout(function() {
49 |       reject('타임아웃');
50 |     }, time);
51 |   });
52 | }
53 | 
54 | Promise.race(foo, timeoutPromise(3000)).then(
55 |   function() {
56 |     //
57 |   },
58 |   function(err) {
59 |     // err
60 |   }
61 | );
62 | ```
63 | 


--------------------------------------------------------------------------------
/Javascript/Some_Every.md:
--------------------------------------------------------------------------------
 1 | # Some과 Every
 2 | 
 3 | 흔히 javascript의 배열과 관련된 메서드로 map, filter, reduce를 생각한다.
 4 | 사실 이 세가지 아니 정확히는 reduce 하나만으로도 모든것을 구현할 수 있다.
 5 | 하지만 언제나 그렇듯 코드의 가독성과 생산성을 위해 다양한 메서드를 알고 있다면 유익하다.
 6 | 
 7 | 이번에 some을 이용해서 코드를 짜볼 기회가 있었어서 알아봤는데 every와 비슷한것 같았다. 자주 사용되지는 않지만 간단하고 꽤나 쓸모가 있는 Some과 Every를 알아봤다.
 8 | 
 9 | ## some
10 | 
11 | some은 배열의 요소가 특정 조건에 한번이라도 만족하는지 검사하는 메서드다.
12 | 
13 | some의 정의는 아래와 같다.
14 | 
15 | > arr.some(callback[, thisArg])
16 | 
17 | - callback
18 |   - currentValue // 현재값
19 |   - index (Optional) // 인덱스
20 |   - array (Optional) // array
21 | - thisArg (Optional) // this
22 | 
23 | 코드로 보자면 아래와 같다.
24 | 
25 | ```js
26 | var array = [1, 2, 3, 4, 5];
27 | 
28 | var isThree = function(element) {
29 |   return element === 3;
30 | };
31 | 
32 | console.log(array.some(isThree)); // true
33 | ```
34 | 
35 | 한번이라도 조건을 만족하면 true다. 조건에 만족하면 그 즉시 true를 리턴한다. 위의 코드의 경우 2번 요소인 3까지만 callback이 실행되고 4부터는 실행되지 않는다.
36 | 
37 | 또한 map, filter와 비슷하게 호출한 배열을 변형하지 않는다.(side effect 최소화)
38 | 
39 | ## every
40 | 
41 | every는 some과 비슷하지만 좀 다르다. 배열의 요소가 특정 조건에 모두 만족하는지 검사하는 메서드다.
42 | 
43 | > every.some(callback[, thisArg])
44 | 
45 | - callback
46 |   - currentValue // 현재값
47 |   - index (Optional) // 인덱스
48 |   - array (Optional) // array
49 | - thisArg (Optional) // this
50 | 
51 | callback에 들어가는 요소도 동일하다.
52 | 
53 | ```js
54 | var array = [10, 20, 30, 40, 50];
55 | 
56 | var overThirty = function(element) {
57 |   return element < 30;
58 | };
59 | 
60 | console.log(array.every(overThirty)); // false
61 | ```
62 | 
63 | 모든 요소가 조건을 만족하면 true다. 즉 모든 경우가 N번 실행되게 된다. some과는 반대로 조건에 만족하지 않으면 그 즉시 true를 리턴한다. 위의 코드의 경우 3번 요소인 40까지만 callback이 실행되고 50은 실행되지 않는다.
64 | 
65 | 이또한 map, filter와 비슷하게 호출한 배열을 변형하지 않는다.(side effect 최소화)
66 | 
67 | ### 결론
68 | 
69 | 실제로 내가 이렇게 사용하기도 했지만, 어떤 작업을 시작하기 전 혹은 작업을 마치고 난 후 null 체크나 값 확인용으로 사용하기 좋은 간단한 메서드다.
70 | 
71 | ---
72 | 
73 | #### 참조
74 | 
75 | - [MDN-Some](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Array/some)
76 | - [MDN-Every](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Array/every)
77 | 


--------------------------------------------------------------------------------
/Javascript/Sync&Async_Multi&Single_Thread.md:
--------------------------------------------------------------------------------
  1 | # Sync & Async, Multi & Single Thread
  2 | 
  3 | ## Sync programming
  4 | 
  5 | 동기 프로그래밍은 쉽게 설명하자면 순차적인 프로그래밍을 이야기한다. 예를들어 파스타를 만들어보자.
  6 | 
  7 | 1. 물을 끓인다. (3분)
  8 | 2. 면을 넣고 10분동안 기다린다. (13분)
  9 | 3. 면을 체에 건진다. (13.5분)
 10 | 4. 마늘과 버섯을 알맞은 크기로 자른다. (15분)
 11 | 5. 팬에 올리브유를 두르고 마늘과 버섯을 넣고 볶는다. (18분)
 12 | 6. 면수와 치킨스톡을 넣고 기름과 섞은 뒤 면을 넣고 30초정도 볶아준다. (20분)
 13 | 
 14 | 1번이 끝나면 2번을 시작, 2번이 끝나면 3번을 시작해서 6번까지 순차적으로 실행하는 방식이 바로 동기 프로그래밍이다.
 15 | 
 16 | ## Async Programming
 17 | 
 18 | 비동기 프로그래밍은 동기의 반대인 순차적이지 않은것이다. 좀 더 정확히는 정해진 순서대로 일을 맡기고 기다리는 방식이다. 방금의 파스타 만들기를 비동기로 바꾸어보자.
 19 | 
 20 | 1. 물을 끓인다.
 21 | 2. 물이 끓는동안 마늘과 버섯을 자른다.
 22 | 3. 물이 끓으면 면을 넣고 10분동안 기다린다. (3분)
 23 | 4. 10분 기다리는 동안 팬에 올리브유를 두르고 마늘과 버섯을 볶는다.
 24 | 5. 면수와 치킨스톡을 넣고 기름과 섞는다.
 25 | 6. 면을 건진 뒤 만든 소스에 넣고 30초정도 볶아준다. (13.5분)
 26 | 
 27 | 동기의 상황과 순서는 조금 다르다. 하지만 본질은 같다. 큰 차이점은 시간이다. 그 이유는 전자는 물이 끓고 면을 삶는동안 기다렸고, 후자는 다른 작업을 했기 때문이다.
 28 | 
 29 | 전자는 물이 끓는동안 나는 할 일이 없다. 하지만 후자는 물을 끓이고 면은 삶아지게 일을 맡겨놓고 나는 다른 일을 처리한다. 다른일을 하다가 물이 끓으면 면을 넣고 다른일을 한다. 면이 다 삶아지면 건지고 또 다른일을 한다.
 30 | 
 31 | ---
 32 | 
 33 | 쓰레드에 대한 이야기를 해보자. 이제는 내가 푸드코트에서 일을 하게 되었다고 생각하자. 저 파스타를 10명이 1그릇씩 주문한다고 하자.
 34 | 
 35 | ## Multi-Thread
 36 | 
 37 | 멀티쓰레드는 주문을 받는 곳이 여러개다. 마치 대형마트의 계산대처럼 말이다. Sync와 Async 두가지 경우가 있을 것이다.
 38 | 
 39 | 만일 계산대가 4개라고 하자.
 40 | 
 41 | ### Multi & Sync
 42 | 
 43 | - 1, 2, 3, 4번 손님을 각각 1, 2, 3, 4번 계산대에 보내 음식을 주문한다.
 44 | - 손님은 계산대에서 음식이 다 완료될때까지 기다리고 음식이 나오면 자리로 간다.
 45 | - 음식이 완료되어 계산대가 비게되면 5번 손님을 빈 계산대로 보낸다.
 46 | 
 47 | ### Multi & Async
 48 | 
 49 | - 1, 2, 3, 4번 손님을 각각 1, 2, 3, 4번 계산대에 보내 음식을 주문한다
 50 | - 주문이 완료되면 자리로 가 번호표를 받고 음식을 기다린다.
 51 | - 계산이 완료되어 계산대가 비게되면 5번 손님을 빈 계산대로 보낸다.
 52 | - 음식이 나오면 번호를 알려주고 음식을 받는다.
 53 | 
 54 | ## Single-Thread
 55 | 
 56 | 싱글쓰레드는 주문을 받는 곳이 한개다. 계산대가 하나인 것이다. 마찬가지로 Sync와 Async의 두가지 경우가 있을 것이다.
 57 | 
 58 | ### Single & Sync
 59 | 
 60 | - 1번 손님을 계산대에 보내 음식을 주문한다.
 61 | - 손님은 계산대에서 음식이 다 완료될때까지 기다리고 음식이 나오면 자리로 간다.
 62 | - 음식이 완료되어 계산대가 비게되면 2번 손님을 빈 계산대로 보낸다.
 63 | 
 64 | ### Single & Async
 65 | 
 66 | - 1번 손님을 계산대에 보내 음식을 주문한다
 67 | - 주문이 완료되면 자리로 가 번호표를 받고 음식을 기다린다.
 68 | - 계산이 완료되어 계산대가 비게되면 2번 손님을 빈 계산대로 보낸다.
 69 | - 음식이 나오면 번호를 알려주고 음식을 받는다.
 70 | 
 71 | 정리하자면 멀티쓰레드는 10가지 업무를 나누어 처리하고 싱글쓰레드는 10가지 업무를 차례대로 처리한다.
 72 | 
 73 | ## 장단점
 74 | 
 75 | 멀티쓰레드
 76 | 
 77 | - 여러가지 업무를 동시에 처리할 수 있다. 따라서 빠른 업무가 가능하고 기다림이 적다.
 78 | - 계산대에 모두 손님을 보내고 남은 사람들이 한줄서기처럼 기다린다면, 빈 계산대를 찾아 보내주는 관리자가 필요하다.
 79 | - 공유 자원이 있다면 관리가 필요하다. 이를 block / lock이라고 한다.
 80 | 
 81 | 싱글쓰레드
 82 | 
 83 | - 순차적이라 복잡하지 않고 block과 관리비용이 없다.
 84 | - 다만 한번에 하나밖에 못한다.
 85 | 
 86 | ## Javascript
 87 | 
 88 | 자바스크립트는 싱글쓰레드에 Async 방식을 사용한다.
 89 | 
 90 | 작업공간인 쓰레드는 하나지만 Async를 사용하여 시간을 공유한다. 면이 삶아지는 동안 소스를 만드는 것처럼 시간을 공유하는 것이다.
 91 | 
 92 | 기본적으로 자바스크립트에서는 event를 이용해 Async를 구현한다. 화면을 클릭하거나 스크롤, 사용자의 입력, 화면의 사이즈 등 event가 발생하면 callback을 실행한다.
 93 | 
 94 | 또한 AJAX와 같은 기술로 외부와 통신한다던가 하는 작업을 비동기로 처리한다.
 95 | 
 96 | 그래서 유명한 다음 그림이 나온다.
 97 | 
 98 | ![javascript_execute](/assets/images/Sync&Async_Multi&Single_Thread_1.jpg)
 99 | 
100 | 이를 더 자세히 보려면 이제 이벤트루프에 대한 개념이 필요하다. 이는 [eventLoop](https://github.com/Im-D/Dev-Docs/blob/master/Javascript/EventLoop.md) 에서 설명한다.
101 | 


--------------------------------------------------------------------------------
/Javascript/object_create_pattern-constructor.md:
--------------------------------------------------------------------------------
  1 | # 객체 생성 패턴 - 생성자 패턴
  2 | 
  3 | 객체를 생성하는 쉽고 단순한 방법에는 `Object` 객체의 인스턴스를 만드는 것과 객체 리터럴을 이용한 방법이 있다.
  4 | 
  5 | ```js
  6 | // Object의 인스턴스 생성
  7 | var person = new Object();
  8 | person.name = "per";
  9 | person.age = 22;
 10 | person.getName = function() {
 11 |     return this.name;
 12 | }
 13 | 
 14 | // 객체 리터럴 사용
 15 | var person = {
 16 |     name : "son",
 17 |     age : 28,
 18 |     getName : function() {
 19 |         return this.name;
 20 |     }
 21 | }
 22 | ```
 23 | 
 24 | > `var person = {}` 과 `var person = new Object()` 는 같은 동작을 한다.
 25 | 
 26 | 객체를 하나만 만든다면 상관없지만, 같은 인터페이스를 가지는 객체를 여러개 만들 경우 비효율적이다. 간단한 팩토리를 사용하여 이를 해결할 수 있다.
 27 | 
 28 | <br/>
 29 | 
 30 | ```js
 31 | function createPerson(name, age) {
 32 |   var obj = {};
 33 | 
 34 |   obj.name = name;
 35 |   obj.age = age;
 36 | 
 37 |   obj.getName= function() {
 38 |     return this.name;
 39 |   };
 40 |   return obj;
 41 | }
 42 | 
 43 | var person1 = createPerson("per", 22);
 44 | var person2 = createPerson("son", 28);
 45 | 
 46 | person1.getName(); // per
 47 | person2.getName(); // son
 48 |  ```
 49 | 
 50 | 하지만 위의 경우 생성된 객체의 타입이 명확하지 않다.
 51 | 
 52 | ```js
 53 | typeof person1; // object
 54 | typeof person2; // object
 55 | ```
 56 | 
 57 | 때문에 생성자 패턴을 사용한다.
 58 | 
 59 | <br/>
 60 | 
 61 | ## 생성자 패턴
 62 | 
 63 | ```js
 64 | function Person(name, age) {
 65 |   this.name = name;
 66 |   this.age = age;
 67 |   this.getName = function() {
 68 |     return this.name;
 69 |   }
 70 | }
 71 | // new 연산자로 새 객체를 만듭니다.
 72 | var person1 = new Person("per", 22);
 73 | var person2 = new Person("son", 28);
 74 | 
 75 | consol.log(person1 instanceof Person); // true
 76 | consol.log(person2.constructor == Person); // true
 77 | ```
 78 | 
 79 | 하지만 생성자 패턴만 사용할 경우 문제점이 있다.
 80 | 
 81 | ### 문제점 1 - 함수로 동작하는 생성자
 82 | 
 83 | 생성자 함수는 함수 타입이기 때문에 new 연산자를 사용하지 않을 경우 함수와 같은 동작을 한다.
 84 | 
 85 | ```js
 86 | Person("person", 99); // 프로퍼티와 메서드가 window객체에 추가된다.
 87 | 
 88 | window.getName() // person
 89 | ```
 90 | 
 91 | ### 문제점 2 - 인스턴스마다 새로운 메소드 생성
 92 | 
 93 | ```js
 94 | function Person(name, age) {
 95 |   this.name = name;
 96 |   this.age = age;
 97 |   // 위에서 만들었던 getName 메소드들은 다음과 같다.
 98 |   this.getName = new Function('return this.name;');
 99 | }
100 | 
101 | var person1 = new Person("per", 22);
102 | var person2 = new Person("son", 28);
103 | 
104 | console.log(person1.getName == person2.getName); // false
105 | ```
106 | 
107 | `getName` 메소드는 계속해서 같은 동작을 하지만, 매번 새로 생겨날 것이다. 메소드를 생성자 바깥에 정의하여 해결할 수 있다.
108 | 
109 | ```js
110 | function getName () {
111 |   return this.name;
112 | }
113 | 
114 | function Person(name, age) {
115 |   this.name = name;
116 |   this.age = age;
117 |   this.getName = getName;
118 | }
119 | 
120 | var person1 = new Person("per", 22);
121 | var person2 = new Person("son", 28);
122 | 
123 | console.log(person1.getName == person2.getName); // true
124 | ```
125 | 
126 | 이렇게하면 메소드가 새로 생겨나는 것은 막을 수 있겠지만, 전역스코프에 함수를 정의한다는 문제가 있다.
127 | 
128 | 이는 프로토타입을 이용하여 해결할 수 있다.
129 | 
130 | <br/>
131 | 
132 | ---
133 | 
134 | Reference
135 | 
136 | - [객체 생성 - 이지코드](http://ezcode.kr/study/view/203)
137 | 


--------------------------------------------------------------------------------
/Javascript/throttling과 rAF.md:
--------------------------------------------------------------------------------
 1 | # throttling과 rAF
 2 | 
 3 | ## throttling(쓰로틀링)
 4 | 
 5 | `Throttling`은 스크롤 이벤트에서 주로 사용되는 기술로 지나치게 많은 이벤트가 발생하는 것을 몇 초에 한 번, 또는 몇 밀리초에 한 번씩만 실행되게 제한을 두는 것이다.<br/>
 6 | 
 7 | ```js
 8 | var timer;
 9 | document.querySelector('#input2').addEventListener('input', function (e) {
10 |     if (!timer) {
11 |         timer = setTimeout(function() {
12 |             timer = null;
13 |             console.log('ajax 요청', e.target.value);
14 |         }, 2000);
15 |     }
16 | });
17 | ```
18 | 
19 | 위의 코드에서 보다시피 `setTimeout`을 이용하여 2초 동안에 한 번만 ajax요청을 하도록 하고 있다. 하지만 `setTimeout`은 지정된 시간 뒤에 무조건 실행되는 것을 보장할 수 없다. 위의 코드는 2초 뒤에 콜백 함수를 실행하는 것이 아니라 2초 뒤에 `Task Queue`에 넣는 것을 의미한다. <br/>**`Task Queue`에 들어간 함수는 순차적으로 `Call Stack`에 옮겨지고 실행**되는데 만약 `Call Stack`이 비워져 있지 않다면, 지정한 시간 이후에 실행되는 것을 보장할 수 없다.
20 | 
21 | <br/>
22 | 
23 | ## requestAnimationFram(rAF)
24 | 
25 | **`rAF`는 브라우저의 최적화 상태를 고려하여 이벤트를 실행**한다. 즉, `setTimeout`처럼 무조건 지정된 시간에 한 번씩 이벤트를 트리거하지 않아도 된다.
26 | Jbee님 포스팅 중 [스크롤 이벤트 최적화](https://jbee.io/web/optimize-scroll-event/)를 보면 `rAF`를 이용하여 스크롤 이벤트를 구현하는 방식을 살펴 볼 수 있는데 간단히 보면 다음과 같다.
27 | 
28 | ```js
29 | function rAFScroll(callback) {
30 |   let tick = false
31 | 
32 |   return function trigger() {
33 |     if (tick) {
34 |       return;
35 |     }
36 | 
37 |     tick = true
38 |     return requestAnimationFrame(function task() {
39 |       tick = false
40 |       return callback();
41 |     })
42 |   }
43 | }
44 | ```
45 | 
46 | `trigger`함수를 보면 `tick`의 값이 `false`일 경우에만 `requestAnimationFrame`의 콜백이 실행된다. <br/>즉, **콜백 함수(`callback`)가 `rAF`에 의해 브라우저가 최적화된 상태에서만 `tick`의 값이 `false`가 되고 실행**된다. 순차적으로 정리하면 다음과 같다.
47 | 
48 | 1. `rAF`의 콜백 함수인 `task`함수가 `animation frame`에 들어간다.
49 | 2. `tick`의 값이 `true`라면 `trigger`함수가 호출되어도 콜백 함수가 실행되지 않는다.
50 | 3. `task`함수가 실행되면서 `tick`이 `false`가 되면 다시 콜백 함수가 실행될 수 있는 환경이 된다.
51 | 
52 | 이처럼 쓰로틀링을 사용하지 않고 `rAF`을 사용하여 이벤트 최적화가 가능하며 `rAF`는 애니메이션의 최적화에도 많이 사용되는 API이기 때문에 잘 알아두는게 좋다.
53 | 
54 | <br/>
55 | 
56 | ---
57 | 
58 | #### Reference
59 | 
60 | - [스크롤 이벤트 최적화](https://jbee.io/web/optimize-scroll-event/)
61 | - [쓰로틀링과 디바운싱](https://www.zerocho.com/category/Javascript/post/59a8e9cb15ac0000182794fa)
62 | 
63 | 


--------------------------------------------------------------------------------
/Javascript/underscore와 lodash그리고 Native.md:
--------------------------------------------------------------------------------
 1 | # underscore와 lodash 그리고 native
 2 | 
 3 | `underscore`와 `lodash`는 자바스크립트 개발을 진행하다보면 많이 듣게 되는 라이브러리다.<br/> 이 둘은 모두 자바스크립트의 **유티릴리성 라이브러리**로서 개발 중 자주 사용하게 되는 함수들을 정의하고 있다. 또한 Native 즉, 일반적으로 `ECMAScript`에서 지원해왔던 함수에도 유틸리성 함수는 존재한다.
 4 | 
 5 | <br/>
 6 | 
 7 | ## underscore / lodash
 8 | 
 9 | ---
10 | 
11 | `underscore`는자바스크립트의 함수형 프로그래밍에 초점을 맞춘 유틸리티성 라이브러리로 `Backbone`에 의존성을 가지고 있다.<br/>`lodash` 또한 자바스크립트 유틸리티성 라이브러리로 크로스환경에 더 안전성을 주고자 하는데 목적이 있다.
12 | 
13 | 현재는 `underscore`의 superset 형태로 함수, 문서, 유닛 테스트, 성능이 더 뛰어나다고 한다.
14 | 
15 | `lodash`는 `underscore`의 API를 구현함과 동시에 `underscore`에 존재하지 않는 함수들도 추가로 개발하였다. `lodash`의 성능이 `underscore`보다 더 좋다고들 한다.
16 | 
17 | 이 두 라이브러리는 모두 `_func()`의 형태로서 배열을 예로 들어보자.
18 | 
19 | ```js
20 | //lodash
21 | _.forEach([4, 8], console.log(n * n)); //16, 64
22 | 
23 | //underscore
24 | _.each([4, 8], console.log(n * n));
25 | ```
26 | 
27 | <br/>
28 | 
29 | ## Native
30 | 
31 | ---
32 | 
33 | 위와 같은 예를 자바스크립트의 기본 메서드만 활용하여 구현해보면 다음과 같다.
34 | 
35 | ```js
36 | [4, 8].forEach(item => console.log(item * item);); //16, 64
37 | ```
38 | 
39 | 코드로만 봤을때는 별 차이가 없지만 중요한 차이는 `lodash`와 `underscore`에서느 배열을 인자로 전달한다는 것이다.
40 | 
41 | 기본적으로 `arr.forEach()`의 경우에 **`arr`가 배열이 아닌 경우 에러가 발생**한다. **하지만 `lodash`와 `underscore`에서는 에러가 발생하지 않는다.** 즉, 스크립트가 뻗지 않는다.
42 | 
43 | 예를 들어, `document.getElementByClassName()`으로 얻은 값은 배열이 아닌 유사배열객체이기 때문에 `forEach`를 돌렸을 때 에러가 발생할 것이다. 하지만, 위 2개의 라이브러리는 에러를 발생시키지 않고 정상적으로 동작한다.
44 | 
45 | ```js
46 | document.getElementsByClassName('className').forEach(item=>{ console.log(item) }); 
47 | //Uncaught TypeError: document.getElementsByClassName(...).forEach is not a function
48 | ```
49 | 
50 | 당연히 개발자가 위와 같은 에러가 발생하지 않도록 예외 처리를 잘해줘야 겠지만, `lodash`나 `underscore`를 사용하면 이런 예외 처리를 해줄 필요가 없다.
51 | 
52 | <br/>
53 | 
54 | ## underscore / lodash vs Native
55 | 
56 | `underscore`나 `lodash`는 다양한 용도의 메서드가 제공된다. 이 부분은 `JS`의 내장함수로는 얻을 수 없는 명확한 이점이다. 또한 **두 라이브러리는 다양한 객체 타입에서도 사용 가능하기 때문에 데이터 처리를 하는데 있어서 유용**하다. 이에 따라 상당한 **생산성 향상**으로 이어질 수 있다.
57 | 
58 | 하지만 기본 JS 내장함수를 사용하는 것이 **성능 상 유리**하고 **협업시 라이브러리의 사용보다는 기본 내장 함수를 사용하는 것이 유지보수 측면에서도 유리**할 것이다.<br/> 또한 브라우저와의 **호환성 문제**도 무시할 수는 없을 것이다. `lodash`의 경우에는 V8엔진에서만 지원하기 때문이다.
59 | 
60 | 또한 JS는 ES6의 등장으로 ES5의 한계를 많이 극복했다.
61 | 
62 | ```js
63 | [...document.getElementsByClassName('className')].forEach(item=>{ console.log(item) });
64 | ```
65 | 
66 | 위와 같이 ES6의 `Spread`를 이용하여 충분히 유사배열객체를 배열로 쉽게 변환할 수 있다.
67 | 
68 | <br/>
69 | 
70 | ---
71 | 
72 | #### Reference
73 | 
74 | - [underscore Docs](https://underscorejs.org/)
75 | - [lodash Docs](https://lodash.com/docs/4.17.11)
76 | - [native vs lodash vs underscore in javaScript(>ES5)](http://blog.kazikai.net/?p=180)
77 | 


--------------------------------------------------------------------------------
/Javascript/렉시컬_속이기(eval).md:
--------------------------------------------------------------------------------
 1 | # 렉시컬 속이기 - eval()
 2 | 
 3 | 주변에서 eval은 사용하면 안된다고들 말한다. 왜 그런지 깊숙하게 알아보았다.
 4 | 
 5 | 자바스크립트에는 렉시컬 스코프라는 개념이 있다. 이를 알기 위해선 scope에 대한 정의가 필요하다.
 6 | 
 7 | ## 스코프와 렉시컬 스코프란
 8 | 
 9 | **스코프**란 자바스크립트 엔진이 Identifier(확인자, 구별자)로 현재 스코프 혹은 그 상위의 스코프 내에서 변수를 찾아내는(LHS, RHS) 규칙을 얘기한다. LHS와 RHS는 추후 설명하겠다.
10 | 
11 | 쉽게말해 자바스크립트 엔진이 변수를 찾는 규칙이다. 지식을 늘려보자.
12 | 
13 | **렉시컬 스코프**를 이해하려면 자바스크립트의 컴파일에 대해 조금 알아야 한다.
14 | 
15 | _기본적으로 자바스크립트는 컴파일 언어다._ 이에 대해서도 다음에 한번 더 다루겠다.
16 | 컴파일에는 크게 세가지 단계가 존재한다.
17 | 
18 | 1. 토크나이징/렉싱 - 코드를 잘게 나누어 토큰으로 만든다.
19 | 2. 파싱 - 나눈 토큰을 의미있게 AST(Abstract Syntax Tree)라는 트리로 만든다.
20 | 3. 코드생성 - AST를 기계어로 만든다.
21 | 
22 | 렉시컬 스코프란 저 1단계에서 발생하는 즉, 렉싱 과정에서 정의되는 스코프를 말한다. 무슨소리냐면 프로그래머가 변수와 스코프 블록을 어떻게 구성하는냐에 따라, 컴파일의 렉싱 타임에서 정의되는 스코프의 방식을 렉시컬 스코프라고 한다.
23 | 
24 | ## 렉시컬 속이기
25 | 
26 | 어려운 얘기였지만 쉽게 말하면 프로그래머가 코드를 어떻게 작성하는지에 따라 엔진이 판단하고 스코프를 만드는게 렉시컬 스코프다. 즉 컴파일 과정에서 발생한다. 그런데 이를 런타임 과정에서 수정하게 되면 렉시컬을 속일 수 있다.
27 | 
28 | 방법은 크게 두가지다. Eval과 With가 있다.
29 | 
30 | With의 경우 최근 거의 사용하지 않는다. 다만 Eval 은 옛날 코드에서 종종 발견된다.
31 | 구글링을 하다보면 Eval을 사용하지 말아라! 라는 말을 종종 보게 된다. 단순히 Eval을 사용하지 말자가 아니라 왜 사용하면 안되는지에 대해서 알아보자.
32 | 
33 | ### Eval
34 | 
35 | ---
36 | 
37 | `eval()` 함수는 받아들인 파라미터를 마치 코드처럼 실행하는 함수다. 직접 코드를 보자.
38 | 
39 | ```js
40 | function foo(str, a) {
41 |   eval(str);
42 |   console.log(a, b);
43 | }
44 | 
45 | var b = 2;
46 | foo('var b = 3;', 1); // 출력되는 a와 b는 각각 1, 3
47 | ```
48 | 
49 | 여기서 `var b = 3;`은 마치 원래 있던 코드처럼 실행되고 이 코드가 새로운 변수 b를 선언하고 초기화하며 이미 존재하는 foo()의 렉시컬 스코프를 수정하게 된다. 즉 foo()안에 변수 b를 만들어 바깥 스코프의 변수 b를 가리게 된다. 이를 Shadowing 이라고 한다.
50 | 
51 | 렉시컬 스코프의 기본 정의는 프로그래머가 코딩을 할 때 정한 스코프이며 이는 **컴파일** 과정에서 만들어진다.
52 | eval()과 같은 함수는 이미 정의된 스코프를 **런타임** 시 수정할 수 있게 된다. 즉 정의를 흔드는 행위다.
53 | 
54 | 이와 비슷한 효과를 내는 함수로는 `setTimeout(), setInterval()`과 같은 함수들이 있다. 또한 `new Function()`도 비슷한 방식으로 동적으로 렉시컬 스코프를 변경한다. 개념은 조금씩 다르지만 근본적으로 이 함수들의 공통점은 렉시컬 스코프를 변경할 수 있다는 점이다.
55 | 
56 | ## 결론
57 | 
58 | 흔히들 주변에서 `eval()`을 사용하면 안된다고들 알려준다. 뭐 성능이 안좋다라는 이야기들을 들을 수 있다. 근데 프로그래머라면 항상 의심해봐야 한다. 진짜 안좋을까?
59 | 
60 | 장점도 물론 있다. 코딩의 유연성? 같은 요소들 말이다.
61 | 
62 | 그렇지만 단점이 너무 치명적이다. 자바스크립트는 다시 말하지만 컴파일 언어다. 이 컴파일 언어는 컴파일 단계에서 최적화 작업을 진행한다. 예를들어 렉시컬 스코프를 만들어 Identifier를 미리 확인하여 추후 Identifier 검색을 빠르게 만든다.
63 | 
64 | 그런데 eval()과 같이 이 렉시컬 스코프를 뒤흔들 수 있는 함수를 사용한다고 하자. 그러면 이미 확인했던 Identifier의 위치가 달라질 수 있다. 즉 기존에 진행했던 최적화작업이 확실하지 않을 수 있게 된다는 점이다. 불확실한 작업을 할 수는 없다. 즉 하나마나한 최적화 작업이 되어 버린다.
65 | 
66 | 즉 엔진이 프로그래머가 작성한 코드를 바탕으로 렉시컬 스코프를 만든다. 이를통해 최적화 작업을 수행한다. 그런데 `eval()`을 사용하게 되면 이 렉시컬 스코프를 수정할 수 있게된다. 이러한 가정 때문에 최적화 작업은 무효화 된다. 따라서 `eval()`과 같은 함수는 사용하지 않는것이 적절하다.
67 | 


--------------------------------------------------------------------------------
/Javascript/상태관리 라이브러리.md:
--------------------------------------------------------------------------------
 1 | # 상태관리 라이브러리
 2 | 
 3 | <br/>
 4 | 
 5 | ## 상태관리 라이브러리의 필요성
 6 | 
 7 | **'상태관리 라이브러리는 왜 필요할까?'** 라는 것에 초점을 두어야 한다.
 8 | 
 9 | **규모가 작은 프로젝트**라면 굳이 상태관리 라이브러리를 사용할 필요는 없다.
10 | 
11 | React를 예로 들면, 16.3 버전에서부터 **Context API** 가 더욱 좋아지면서 글로벌 상태 관리 또한 별도의 라이브러리 없이 할 수 있게 되었다.
12 | 
13 | 하지만, **프로젝트의 규모가 커지면서**  `setState`로 상태를 구성하고, 이를 `props`로 넘겨주는 등의 일이 점점 복잡해진다.<br/> 뿐만 아니라 **상태 업데이트 로직이 컴포넌트 별로 존재**하면서 유지보수가 어려워질 수 있다.
14 | 
15 | 사실, 상태관리 라이브러리를 사용하는 이유를 말하자면 간단하다.
16 | 
17 | > 애플리케이션의 상태를 **단일 스토어**에서 관리하고 상태의 흐름을 **단방향**으로 통일하기 위해서이다.
18 | 
19 | React에서 주로 사용되는 상태관리 라이브러리에는 **Redux**와 **Mobx**가 있다.
20 | 
21 | <br/>
22 | 
23 | ## Flux Architecture
24 | 
25 | Flux 구조는 MVC 구조의 Model, View, Controller의 역할 배분의 구조가 아닌 **이벤트와 데이터의 흐름에 집중**한다.
26 | 
27 | Facebook을 예로 들면, 타임라인만 봐도 수많은 사람들이 매번 글을 올리고 그 글에 몇천, 몇만명의 사람들이 댓글을 쓰고 좋아요를 누른다.
28 | 
29 | 이런 복잡한 **데이터 흐름을 단방향으로 통일**시킴으로써 문제를 해결한 것이 Flux 구조다.
30 | 
31 | ![flux_architecture](/assets/images/flux_architecture.png)
32 | 
33 | - **Action** : 앱에서 발생한 **이벤트(조작), 데이터의 변화**에 대한 정보를 담고 있다. Action이 만들어지는 것만으로는 앱에 변화를 주진 않는다.
34 | 
35 | - **Dispatcher** : Action을 **순서대로** Store로 전달하는 역할을 한다.
36 | 
37 | - **Store, View** : Dispatcher로 받은 Action을 기반으로 Store 내의 상태를 변경하고 이를 View에 반영하여 화면에 그린다.
38 | 
39 | Flux 구조를 사용한 대표적인 라이브러리가 **Redux**와 **Mobx**다.
40 | 
41 | <br/>
42 | 
43 | ## Redux vs Mobx
44 | 
45 | ### Redux
46 | 
47 | ---
48 | 
49 | - **단 하나의 스토어**를 애플리케이션의 모든 상태를 관리한다. 이는 애플리케이션의 상태를 예측가능하기 쉽게 한다.
50 | 
51 | - **함수형 프로그래밍 패러다임**을 기본적으로 따른다. 익숙하지 않은 개발자들에게는 낯설 수 있다.
52 | 
53 | - **불변성**을 필수적으로 지켜줘야한다.
54 | 
55 | - 하나의 스토어로 관리하기 때문에 애플리케이션 전체의 흐름을 잘 통제하는 만큼 수많은 Dispatcher가 발생했을 때 병목현상이 발생할 수 있다.(이를 막기 위해 `Redux-thunk`나 `Redux-saga`와 같은 **미들웨어를 사용**한다.)
56 | 
57 | ### Mobx
58 | 
59 | ---
60 | 
61 | - **다수의 스토어**를 가질 수 있고 **기본적으로 Observable을 사용**한다. 이는 Redux보다 데이터 흐름을 쉽게 관리할 수 있게 한다.
62 | 
63 | - Redux에서 중요하게 신경썼던 **불변성을 신경쓰지 않아도 된다.**
64 | 
65 | - 새롭게 알아야하는 개념(Reducer, Immutable, connect, Action, Dispatcher, 미들웨어)이 많은 Redux에 비해 **Running-Curve가 적다고 한다.**
66 | 
67 | <br/>
68 | 
69 | ---
70 | 
71 | #### Reference
72 | 
73 | - [Mungue Lee님의 Medium](https://medium.com/@RianCommunity/%EB%A6%AC%EC%95%88-%EA%B0%9C%EB%B0%9C-%EC%9D%BC%EA%B8%B0-2-front-end-%EA%B0%9C%EB%B0%9C-react-9f6ccb5b016d)
74 | - [상태 관리 라이브러리의 미학: Redux 또는 MobX 를 통한 상태 관리](https://velog.io/@velopert/redux-or-mobx)
75 | - [Immutable.js 혹은 Immer.js 를 사용한 더 쉬운 불변성 관리](https://velog.io/@velopert/20180908-1909-%EC%9E%91%EC%84%B1%EB%90%A8-etjltaigd1)
76 | 


--------------------------------------------------------------------------------
/Javascript/클로저.md:
--------------------------------------------------------------------------------
 1 | # 클로저
 2 | 
 3 | <br/> 
 4 | 
 5 | ## 렉시컬 스코프란
 6 | 
 7 | 
 8 | ```js
 9 | function outerFunc() {
10 |     var x = 10;
11 |     var innerFunc = function() {console.log(x);};
12 |     innerFunc();
13 | }
14 | 
15 | outerFunc(); // 10
16 | ```
17 | 
18 | ```js
19 | var x = 1;
20 | 
21 | function outerFunc(){
22 |     var x = 10;
23 |     innerFunc();
24 | }
25 | 
26 | function innerFunc() {
27 |     console.log(x);
28 | }
29 | 
30 | outerFunc(); // 1
31 | ```
32 | 
33 | 함수의 상위 스코프는 **함수가 어디서 호출되었는지** 또는 **함수를 어디서 선언하였는지**에 따라 결정된다. 첫번째 방식을 **동적 스코프(Dynamic scope)**, 두번째 방식을 **렉시컬 스코프(lexical scope)** 또는 정적 스코프(static scope)라고 한다. 자바스크립트를 포함한 대부분의 언어가 렉시컬 스코프를 따른다.  
34 | 
35 | 따라서 첫번째 예제에서 `innerFunc()`의 상위 스코프는 `outerFunc()`와 `전역 스코프`가 되고, 두번째 예제에서 `innerFunc()`의 상위 스코프는 `전역 스코프`가 된다. 
36 | 
37 | <br/>
38 | 
39 | ## 스코프 체인  
40 | 
41 | 스코프 체인은 **하위 함수가 참조하는 상위 함수의 변수 또는 함수의 메모리를 참조하는 것**을 말한다. 스코프 체인에는 렉시컬 스코프의 레퍼런스가 차례대로 저장되어 있고, 이 순서를 따라 자바스크립트 엔진이 검색을 한다.   
42 | 
43 | 첫번째 예제의 스코프 체인을 나타내면 다음과 같다.  
44 | 
45 | ![scopechain](/assets/images/ScopeChain.png)  
46 | 
47 | 자바스크립트 엔진은 `innerFunc()` 스코프 내에서 변수 `x`를 검색한다. `x`가 없기 때문에 다음 리스트인 `outerFunc()`의 스코프 내에서 `x`를 검색한다. 그리고 `outerFunc()`에서 찾은 `x`를 참조해 결과를 반환한다. 
48 | 
49 | <br/>
50 | 
51 | ## 클로저란
52 | 
53 | 이번에는 `outerFunc()`이 내부함수를 반환하고 소멸하도록 바꿔보자.
54 | 
55 | ```js
56 | function outerFunc() {
57 |     var x = 10;
58 |     return {
59 |         innerFunc1 : function(){ console.log(x+1)}
60 |         , innerFunc2 : function(){ console.log(x+2)}
61 |     }
62 | }
63 | 
64 | var inner = outerFunc();
65 | inner.innerFunc1();
66 | inner.innerFunc2();
67 | ```
68 | `outerFunc()`이 소멸되고 `inner()`에는 `innerFunc1()`과 `innerFunc2()`가 담겨있다.  
69 | `innerFunc1()`과 `innerFunc2()`는 `outerFunc()`의 `x` 변수를 참조했었는데, `outerFunc()`가 소멸되었으므로 `x`를 참조하지 못할 것 같지만, 각각의 결과로 11, 12가 정상 출력된다.   
70 | 이처럼 **생명주기가 끝난 외부함수의 변수를 참조하는 방법을 클로저**라고 한다. 클로저는 **자신이 선언되었을 때의 환경(lexical Environment), 즉 스코프**를 기억해, 선언된 환경 밖에서 호출되어도 해당 환경에 접근할 수 있는 함수이다.  
71 | 
72 | 클로저가 가능한 이유는 `outerFunc()`의 실행컨텍스트는 소멸되지만 `활성화 객체(AO)`는 **소멸되지 않기 때문**이다. 때문에 `innerFunc1()`과 `innerFunc2()`의 ScopeChain은 유지되어 자바스크립트는 `x`변수를 `outerFunc()`에서 검색할 수 있다. 즉, 클로저는 실제 변수의 복사본이 아닌 그 변수를 직접 참조한다. 
73 | 
74 | <br/>
75 | 
76 | #### Reference
77 | * [클로저](https://poiemaweb.com/js-closure)
78 | * [JavaScript : Scope 이해](http://www.nextree.co.kr/p7363/)
79 | * [실행 컨텍스트와 자바스크립트의 동작 원리](https://poiemaweb.com/js-execution-context)
80 | 
81 | 


--------------------------------------------------------------------------------
/Javascript/함수 선언.md:
--------------------------------------------------------------------------------
  1 | # 함수 선언식 / 함수 표현식
  2 | 연산자 `function`을 이용해 함수를 정의하는 방법에는 함수 선언식과 함수 표현식이 있다.  
  3 | 
  4 | ## 함수 선언식
  5 | ```javascript       
  6 | function fnc() {    
  7 |     /*실행코드*/
  8 | }
  9 | ```  
 10 | 함수 선언식으로 정의된 함수는 자바스크립트가 로딩되는 시점에 인터프리터가 초기화하고 VO에 저장된다. 따라서 함수 선언 위치와 상관없이 소스 내 어느 곳에서든지 호출이 가능하다.   
 11 | <br/>  
 12 |  
 13 | ## 함수 표현식
 14 | ```javascript
 15 | //변수에 할당
 16 | var fnc = function fnc() {
 17 |     /*실행코드*/
 18 | };
 19 | 
 20 | var fnc = function() {
 21 |     /*실행코드*/
 22 | }
 23 | 
 24 | //즉시실행함수
 25 | (function fnc(){
 26 | 
 27 | }());
 28 | 
 29 | (function(){
 30 | 
 31 | }());
 32 | ```
 33 | 함수표현식은 자바스크립트 로딩시점에 VO에 함수를 저장되지 않고, runtime시에 해석된다. 
 34 | <br/>  
 35 | 따라서 함수 선언식으로 함수를 정의하면 사용하기 쉽지만, 너무 많은 코드가 VO에 저장되어 애플리케이션의 응답속도가 느려질 수 있다는 것을 주의해야한다. 
 36 | <br/>  
 37 | 하지만, 스크립트 파일을 모듈화하고 비동기 방식으로 로딩할 경우 응답속도를 향상시킬 수 있다.  
 38 | 
 39 | <br/>     
 40 | 
 41 | 
 42 | # 익명함수 / 기명함수
 43 | 
 44 | ```javascript
 45 | function add(x, y){
 46 |     return x+y;
 47 | }
 48 | ```
 49 | 위와 같이 정의된 함수는 자바스크립트 엔진에 의해 다음과 같이 바뀐다. 
 50 | 
 51 | ```javascript
 52 | var add = function add(x,y) {
 53 |     return x+y;
 54 | };
 55 | ```
 56 | 즉, 기명함수와 같은 이름에 함수가 변수로 선언된다. (함수변수)  따라서 `add(3, 5)`와 같은 명령을 내리면 이는 함수변수의 내부 함수에 접근한 것이 아니라 함수변수에 접근한 것이다. 다음은 함수변수와 내부함수의 이름이 다른 경우이다. 
 57 | 
 58 | ```javascript
 59 | var add = function sum(x, y){
 60 |     return x + y;
 61 | };
 62 | ```
 63 | `sum(3, 5)`를 명령한 경우 sum함수가 정의되지 않았다는 에러가 뜬다. 함수변수의 내부함수에 직접 접근할 수 없기 때문이다. 따라서 `add(3, 5)`와 같이 함수변수를 통해 명령을 내려줘야 한다.   
 64 | 
 65 | <br/>  
 66 | 
 67 | 함수변수의 내부변수는 함수변수 내부에서 디버깅이나 재귀호출에 쓰인다. 다음은 재귀호출의 예이다.
 68 | ```javascript
 69 | var factorialFn = function factorial(x){
 70 |     if(x <= 1){
 71 |         return 1;
 72 |     }
 73 |     return factorial(x-1) * x 
 74 | };
 75 | ```  
 76 | 
 77 | <br/>  
 78 |  
 79 | 
 80 | 
 81 | # arguments
 82 | arguments 객체는 함수를 호출할 때 암묵적으로 내부에 전달되는 **유사객체**이다. (유사객체는 배열이 아니지만 length 속성을 가진 객체를 말한다. 단, 배열처럼 index로 접근하지 못한다.) arguments 객체는 다음과 같은 4가지 property를 가진다. 
 83 | 1. 함수를 호출할 때 전달된 인자 (배열형태)
 84 | 2. length : 인자의 개수
 85 | 3. callee : 호출된 함수
 86 | 4. `__proto__`  
 87 | 
 88 | 위의 property 중 `callee`를 이용하면 addEventListener에서 넘겨준 익명함수를 removeEventListener에서 삭제할 수 있다. 
 89 | 
 90 | ## removeEventListener_익명함수
 91 | 먼저, 기명함수로 addEventListener와 removeEventListener를 사용하면 다음과 같다. 
 92 | 
 93 | ```javascript
 94 | //addEventListener
 95 | document.querySelector("#addEvent").addEventListener("click", fnc);
 96 | 
 97 | //removeEventListener
 98 | document.querySelector("#addEvent").removeEventListener("click", fnc);
 99 | ```
100 | 이 경우 넘겨준 함수가 이름을 가지고 있기 때문에, removeEventListener도 잘 적용된다. 하지만 다음과 같이 익명함수를 전달해주면 removeEventListener가 적용되지 않는다.
101 | 
102 | ```javascript
103 | //addEventListener
104 | document.querySelector("#addEvent").addEventListener("click", function(e){
105 |     var targetId = e.target.id;
106 |     fnc(target);
107 | });
108 | 
109 | //removeEventListener
110 | document.querySelector("#addEvent").removeEventListener("click", function(e){
111 |     var targetId = e.target.id;
112 |     fnc(target);
113 | });
114 | ```
115 | 이 때 arguments의 callee를 이용하면 익명함수로 전달된 함수도 remove해줄 수 있다. 
116 | ```javascript
117 | //removeEventListener
118 | document.querySelector("#addEvent").removeEventListener("click", arguments.callee);
119 | ```  
120 | 
121 | <br/>  
122 | 
123 | ---
124 | 
125 | #### Reference
126 | - [Javascript:함수(function)다시보기] www.nextree.co.kr/p4150
127 | - 인사이드 자바스크립트 송형주, 고현준
128 | 


--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
 1 | MIT License
 2 | 
 3 | Copyright (c) 2018-2020 Im-D
 4 | 
 5 | Permission is hereby granted, free of charge, to any person obtaining a copy
 6 | of this software and associated documentation files (the "Software"), to deal
 7 | in the Software without restriction, including without limitation the rights
 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 9 | copies of the Software, and to permit persons to whom the Software is
10 | furnished to do so, subject to the following conditions:
11 | 
12 | The above copyright notice and this permission notice shall be included in all
13 | copies or substantial portions of the Software.
14 | 
15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21 | SOFTWARE.
22 | 


--------------------------------------------------------------------------------
/Language/Currying.md:
--------------------------------------------------------------------------------
 1 | # Currying
 2 | 
 3 | Currying은 여러 개의 인자를 가진 함수를 호출할 경우, 파라미터의 수보다 적은 수의 파라미터를 인자로 받으면 누락된 파라미터를 인자로 받는 기법을 말한다.
 4 | 부분적으로 인자가 적용된 함수를 체인으로 연결하여 값을 처리하는 것이 본질이다.
 5 | 
 6 | <br/>
 7 | 
 8 | ## 함수의 인자를 분리해서 받는다.
 9 | 
10 | ```js
11 | function add(x){
12 |     return function(y){
13 |         return x + y
14 |     };
15 | };
16 | 
17 | // arrow function으로 한다면 이런 형태일 것이다.
18 | var add = x => y => x + y;
19 | var firstAdd = add(10);
20 | 
21 | add(10); //y => x + y
22 | add(10)(5); //15
23 | firstAdd(5); //15
24 | ```
25 | 
26 | 위 코드를 보면 `add(10)`의 결과가 함수를 반환하는 것을 볼 수 있다. 즉, `add`함수의 인자가 2개라고 했을 때 2개의 인자를 모두 받지 않으면 함수는 실행되지 않는다.
27 | 
28 | 위 처럼 함수의 인자를 분리해서 받으면 어떤 이점이 있을까?
29 | 
30 | - 함수의 실행을 늦출 수 있다.(부분적으로 파라미터를 받게 되면, 모든 파라미터를 받기 전까지 함수는 실행되지 않는다)
31 | - firstAdd 함수처럼 고정적인 부분은 별도로 정의함으로써 재사용이 가능하다.
32 | 
33 | 위의 코드에서는 함수의 인자 개수가 2개로 정해져 있다. 하지만, 함수의 인자가 동적이거나 훨씬 많다면 모든 경우를 생각하여 모든 함수를 각각 만들어줄 수는 없을 것이다. 이때 curry 함수를 구현하여 함수의 인자를 동적으로 받을 수 있다.
34 | 
35 | ```js
36 | Function.prototype.curry = function(one) {
37 |   var origFunc = this;
38 |   var target = origFunc.length;
39 |   var args = [];
40 |   function next(nextOne) {
41 |     args = [...args, nextOne];
42 |     if (args.length === target) {
43 |       return origFunc.apply(null, args);
44 |     } else {
45 |       return nextOne => { return next(nextOne) };
46 |     }
47 |   }
48 |   return next(one);
49 | }
50 | 
51 | const add = (a, b, c, d) => {
52 |   return a + b + c + d;
53 | }
54 | 
55 | add.curry(1)(2)(3)(4); //10
56 | ```
57 | 
58 | <br/>
59 | 
60 | ## 합성함수에서의 Currying
61 | 
62 | [합성함수](https://github.com/Im-D/Dev-Docs/blob/master/Language/%ED%95%A8%EC%88%98%ED%98%95%20%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D.md#%ED%95%A9%EC%84%B1%ED%95%A8%EC%88%98Function-Composition)는 함수형 프로그래밍에서 사용되는 프로그래밍 기법 중 하나로 말그대로 두 가지 이상의 함수가 합성되었음을 뜻한다. 즉, 각각의 역할을 수행하는 함수를 필요에 따라 합성하여 원하는 결과 값을 만들어낸다. 그러려면 합성하는 역할을 하는 함수를 만들어야 하는데 이때 Currying을 사용하여 함수를 구현할 수 있다.
63 | 
64 | 
65 | ```js
66 | const compose = (...fns) => x => fns.reduceRight((v, f) => f(v), x);
67 | 
68 | const square = num => num * num;
69 | const addTen = num => num + 10;
70 | const minusTen = num => num - 10;
71 | 
72 | const squareAfterAddTen = compose(square, addTen);
73 | const squareAfterMinusTen = compose(square, minusTen);
74 | 
75 | console.log(squareAfterAddTen(10)); //400
76 | console.log(squareAfterMinusTen(30)); //400
77 | ```
78 | 
79 | 위의 `compose`함수가 2개 이상의 함수를 합성하는 역할을 해주는 함수다. 코드를 보면 합성할 함수들를 받은 다음 뒤에서 부터 순서대로 실행시키고 그 결과 값을 다음 함수의 인자로 전달하고 있다.
80 | 
81 | 합성 함수의 핵심은 여러 함수를 원하는 경우에 따라 합성하여 사용하고 내부적으로 각각의 함수들이 어떤 로직을 수행하는지에는 관심이 없다는 것이다. 즉, 각각의 함수의 역할만 알고 있으면 이를 상황에 따라 합성하여 사용할 수 있기 때문에 재사용성을 높일 수 있다. 그리고 이러한 장점을 가진 합성 함수를 사용하는데 있어 Currying은 필수적으로 알고 있어야할 개념 중 하나기 때문에 알아둘 필요가 있다.
82 | 
83 | Currying이 함수형 프로그래밍을 위해서 있는 것이 아니며 최근 함수형 프로그래밍에 대한 관심이 높아지면서 Currying의 개념이 다시 한 번 나타나게 된걸로 생각하면 좋을 것 같다.
84 | 
85 | <br/>
86 | 
87 | ---
88 | 
89 | #### Reference
90 | 
91 | - [Zero Cho Blog - Currying(커링) vs Partial application](https://www.zerocho.com/category/JavaScript/post/579236d08241b6f43951af18)
92 | - [JavaScript에서 커링 currying 함수 작성하기](https://edykim.com/ko/post/writing-a-curling-currying-function-in-javascript/)
93 | - [Lazysoul Medium - Currying(커링)](https://medium.com/@lazysoul/currying-%EC%BB%A4%EB%A7%81-b7af0b2aaef1)
94 | 


--------------------------------------------------------------------------------
/Language/Lamda.md:
--------------------------------------------------------------------------------
 1 | # 람다
 2 | 
 3 | ## 람다 대수(Lambda calculus)
 4 | 
 5 | 람다의 근간은 수학에서, 그리고 초기 튜링기계에 사용되었던 *람다 대수 or 람다 계산 (Lambda Calculus)*다. 람다 대수는 수학에서의 함수를 단순하게 표현하는 방법이다. 예를들어 f( g(f(x) g(x))) 이런 수학 기호가 람다 대수다.
 6 | 
 7 | 람다 대수는 다음과 같은 특징이 있다.
 8 | 
 9 | 1. 람다 대수는 이름을 가질 필요가 없다. (익명 함수)
10 | 2. 두 개 이상의 입력이 있는 함수는 최종적으로 1개의 입력만 받는 람다 대수로 단순화 될 수 있다. (커링)
11 | 
12 | 즉 익명함수이면서 커링이 가능하다.
13 | 
14 | ## 익명함수
15 | 
16 | 람다 대수의 영향을 받아 만들어진 함수다. 이름이 없는 함수를 의미한다.
17 | 
18 | 변수 V1이 있는 람다식을 `λV1. V1 x V1`라고 할 때 이를 프로그래밍에서 표현하는 방법은 `x => x * x`다. 이래서 람다 대수의 영향을 받았다고 한다.
19 | 
20 | ```js
21 | var foo = x => x * x;
22 | ```
23 | 
24 | 이렇게 쓰던 화살표 함수가 바로 람다대수의 영향을 받은 익명함수다. 다만 자바스크립트에서는 이렇게 사용하지만 언어별로 지원하는 방법이 조금 다르다. 람다 표현식(expression)만 지원하는 경우와 같은 것이 있다. 그러나 공통점은 모두 일급 객체라는 점이다.
25 | 
26 | ## 일급 객체(first class citizen)
27 | 
28 | 일급객체는 쉽게 설명해서 생성, 대입, 연산, 인자 또는 반환값으로서의 전달 등 기본 연산이 가능한 대상을 말한다.
29 | 
30 | 더 쉽게 설명하자면 변수와 같은 것이다.
31 | 
32 | ```js
33 | var x; // 생성
34 | x = 1; // 대입
35 | var y = 2;
36 | x + y; // 연산
37 | foo(x); // 인자
38 | return x; // 반환값
39 | ```
40 | 
41 | 변수는 생성, 대입, 연산, 인자 또는 반환값으로서의 전달이 모두 가능하다.
42 | 
43 | JS에서는 함수도 마찬가지로 모두 가능하다.
44 | 
45 | 즉 함수가 일급 객체를 지원하면 커링이 가능하며, 거기에 익명함수까지 지원한다면 람다 함수라 할 수 있다.
46 | 
47 | ## 함수형 프로그래밍, HOF(고차함수), 일급객체, 람다
48 | 
49 | 이게 사실 다 연관되는 내용이다.
50 | 
51 | - 일급객체 ⇒ 기본연산이 가능
52 | - 람다 ⇒ 익명 + 커링
53 | - HOF ⇒ 함수를 인수로 취하거나 결과로 반환
54 | - 함수형 프로그래밍 ⇒ 순수함수 + immutable
55 | 
56 | 이렇게 간단하게나마 정리할 수 있다. 4가지의 연결고리는 아래와 같다.
57 | 
58 | 함수가 일급 객체이며, 람다(익명 + 커링) 함수다. 그렇다면 고차함수가 될 수 있다. 고차함수가 되게 함수를 만들고 사용한다면 함수형 프로그래밍에 가까워진다.
59 | 
60 | ## 람다의 특징
61 | 
62 | 코드가 간결해진다. 람다는 불필요한 루프문에 대한 정의를 삭제한다.
63 | 
64 | iteration 방식과 다르다. 0부터 9까지 1씩 증가하면서 실행해라고 명령하는 것이 아니라 그냥 여기 있는거 다 해라고 설명하는 방식이다.
65 | 
66 | 그래서 함수형 프로그래밍과 HOF와 철학이 비슷한것이다.
67 | 
68 | ```js
69 | for (var i = 0; i < 10; i++) {
70 |   console.log(i);
71 | }
72 | 
73 | [0, 1, 2, 3, 4, 5, 6, 7, 8, 9].forEach(console.log);
74 | ```
75 | 
76 | 아래의 방식이 바로 람다 방식이다.
77 | 
78 | ---
79 | 
80 | ### 참고자료
81 | 
82 | - [람다, 익명 함수, 클로저 블로그 글](<[https://hyunseob.github.io/2016/09/17/lambda-anonymous-function-closure/](https://hyunseob.github.io/2016/09/17/lambda-anonymous-function-closure/)>)
83 | - [람다식 나무위키](<[https://namu.wiki/w/람다식](https://namu.wiki/w/%EB%9E%8C%EB%8B%A4%EC%8B%9D)>)
84 | - [람다대수 위키](<[https://ko.wikipedia.org/wiki/람다_대수](https://ko.wikipedia.org/wiki/%EB%9E%8C%EB%8B%A4_%EB%8C%80%EC%88%98)>)
85 | - [Functinonal Programming](https://github.com/Im-D/Dev-Docs/blob/master/Language/Funtional.md)
86 | - [Higher Order Functions](https://github.com/Im-D/Dev-Docs/blob/master/Language/Higher_Order_Functions.md)
87 | 


--------------------------------------------------------------------------------
/Network/JSend.md:
--------------------------------------------------------------------------------
 1 | # JSend
 2 | 
 3 | RESTful하게 개발하는 건 2019년 현재 개발 트렌드다.
 4 | 
 5 | backend - frontend를 완전히 구분하고 자원에 대한 API를 REST하게 설계한다. 이 둘은 JSON 형태로 데이터를 주고받는다.
 6 | 
 7 | REST와 관련된 자료는 아래 두 자료를 참고하자.
 8 | 
 9 | - [Dev-Docs rest](https://github.com/Im-D/Dev-Docs/blob/master/Network/REST.md)
10 | - [그런 rest api로 괜찮은가](https://www.youtube.com/watch?v=RP_f5dMoHFc)
11 | 
12 | 두번째 자료인 그런 rest api로 괜찮은가를 보면 생각보다 rest api를 구축하기는 상당히 어렵다.
13 | 이를 도와주는 약속 중 하나가 JSend다.
14 | 
15 | ## JSend란?
16 | 
17 | [JSend](https://github.com/omniti-labs/jsend)는 JSON 응답에 대한 스펙이다. 
18 | 
19 | [JSON](https://ko.wikipedia.org/wiki/JSON) 형식은 더글라스 크락포드가 만든 key-value형식의 데이터 포맷이다. 형식이 매우 자유로운 편이다. 그래서 유연하다.
20 | 
21 | 대신 문제가 있다. 형식이 자유로운 만큼 표준이 없다. 따라서 사이트마다 응답 데이터의 생김새가 모두 다르다.
22 | 모양이 다른 문제는 결국 front-end 개발자가 개발할 때마다 다른 모양에 맞춰야 한다는 점이다.
23 | 
24 | 사이트마다, 팀마다, 사람마다 response의 포맷은 같지만, 형식이 다르다면 엄청 귀찮은 일이 될 것이다.
25 | 
26 | 이를 해결하고자 나온 아주 간단한 JSON 스펙이 JSend다.
27 | 
28 | ## specification
29 | 
30 | ```js
31 | {
32 |     status : "success",
33 |     data : [
34 |       { "id" : 1, "category" : "A blog post", "body" : "Some useful content" },
35 |       { "id" : 2, "category" : "A Film", "body" : "parasite" }
36 |     ]
37 | }
38 | ```
39 | 생김새는 위와 같다.
40 | 
41 | 꽤 많은 사이트에서 위와 같은 포맷의 response를 확인할 수 있다.
42 | 
43 | 매우 간단한 스펙이다. status와 data를 나눈다.
44 | 
45 | status의 타입도 간단하게 세 가지다.
46 | 
47 | | TYPE    | Description                                                                                         | Required Keys   | Optional Keys |
48 | |---------|-----------------------------------------------------------------------------------------------------|-----------------|---------------|
49 | | success | All went well, and (usually) some data was returned.                                                | status, data    |               |
50 | | fail    | There was a problem with the data submitted, or some pre-condition of the API call wasn't satisfied | status, data    |               |
51 | | error   | An error occurred in processing the request, i.e. an exception was thrown                           | status, message | code, data    |
52 | 
53 | - success: 성공
54 | - fail: 데이터에 어떤 문제가 생겼을 때
55 | - error: 프로세스에서 에러가 발생했을 때
56 | 
57 | ### 참고할만한 사항
58 | 
59 | - data가 null인 경우에도 success일 수 있다. 조회한 데이터의 결과가 null일 수 있기 때문이다.
60 | - post values에 문제가 생겼을 경우 data object의 key가 그 post value와 일치해야 한다.
61 |     ex) title 값이 잘못된 경우 => { "status": "fail", "data" : { "title" : "A title is required" } }
62 | - 에러의 message는 end-user-readable해야한다. error code 같은 것은 optional data로 추가되어야지 message에 들어가면 안 된다.
63 | 
64 | ### 사용이유
65 | 
66 | HTTP의 status가 있다. 그래도 굳이 body에 status를 표기하는 JSend를 사용하는 이유가 있다.
67 | 
68 | HTTP는 상태 코드가 너무 많다. 41개 이상의 상태 코드가 있다. 200, 404와 같은 코드들 말이다.
69 | 표준이 확실히 있는 것은 좋지만 그만큼 관리하기 어렵다는 문제가 있다.
70 | 
71 | 개발자가 41개의 모든 상태 코드를 다 알고 대응해야 한다. 301과 같은 코드들은 사람이 바로 알 수 없다. human-readable하지 않다.
72 | 
73 | JSend는 spec이 작고 제한적이다. application-level의 약속이라 protocol에 반하지도 않는다. 
74 | 따라서 응용도가 높고 독립적으로 응용이 가능하다.
75 | 
76 | 사용하기 편리하고 가볍고 간단한 표준이다. 따라서 개발단계에서 응답 형식에 얽매이지 않고 바로 개발할 수 있기에 이와 같은 규칙을 사용하면 좋다.
77 | 
78 | ---
79 | 
80 | #### 참고자료
81 | 
82 | - [Dev-Docs rest](https://github.com/Im-D/Dev-Docs/blob/master/Network/REST.md)
83 | - [그런 rest api로 괜찮은가](https://www.youtube.com/watch?v=RP_f5dMoHFc)
84 | - [JSend](https://github.com/omniti-labs/jsend)
85 | - [JSend란](https://krksap.tistory.com/1216)


--------------------------------------------------------------------------------
/Network/Switch.md:
--------------------------------------------------------------------------------
 1 | 네트워크 교육을 듣다가 스위치가 layer 계층별로 각각 존재한다는 것을 알게 되었고 더욱 자세히 알고 싶어 정리를 해보았다.
 2 | 
 3 | # 스위치(Switch)
 4 | 스위치란 허브의 확장된 개념으로 기본 기능은 허브와 같지만 전송 중 패킷의 충돌이 일어나지 않도록 패킷의 목적지로 지정할 포트를 직접 전송한다. 소규모 통신을 위한 허브보다 전송 속도가 개선된 것이다. 
 5 | 
 6 | 간단하게 말해서 아래의 사진처럼 인터넷을 할 수 있는 랜선을 꽂을 수 있는 것을 스위치라고 한다. 하나의 네트워크 라인에 여러 대의 컴퓨터를 연결하는 데 필요한 장치이다.  
 7 | 
 8 | ![스위치](https://user-images.githubusercontent.com/43868540/104829776-5ea58800-58ba-11eb-8b42-18e63238c6cd.PNG)
 9 | 
10 | > [출처](https://blog.naver.com/PostView.nhn?blogId=wjw1225&logNo=222147131756)
11 | 
12 | ## 허브와 스위치의 차이
13 | 허브의 경우 전송대역을 여러 대의 네트워크가 나눠 쓰는 단점이 있다. 반면 스위치의 경우는 같은 속도로 분배해준다는 장점이 있다.
14 | 
15 | ![스위치와 허브](https://user-images.githubusercontent.com/43868540/104828795-5cd6c700-58b0-11eb-9c5c-c18f53c02339.PNG)
16 | 
17 | > [출처](https://siran.tistory.com/205)
18 | 
19 | 위에 그림을 보면 허브는 모든 노드가 일정 속도를 나누어 쓰게 되고, 스위치는 네트워크를 동시에 사용 가능해 속도 저하가 거의 없다. 따라서 스위치는 각 Port별로 bandwidth를 제공한다.  
20 | 
21 | ### Layer2 스위치(스위치)
22 | Layer 2에서 동작하는 스위치로, MAC 주소를 보고 데이터를 단순전달해주는 기능을 담당한다. 허브와는 다르게 포트별로 bandwidth가 정해져 데이터를 전달하기 때문에 속도에 저하가 없다. 
23 | 
24 | - 가장 흔히 볼 수 있는 스위칭 방식이며, 원래 스위치의 정의에 가장 부합하는 형태이다. 
25 | - 패킷의 **MAC 주소**를 읽어 스위칭하고, MAC의 OSI 계층 중 2계층에 해당하기 때문에 Layer 2 스위치라 한다. 
26 | - Broadcast 패킷에 의해 성능 저하가 발생한다. 
27 | > Broadcast란 송신 호스트가 전송한 데이터가 네트워크에 연결된 모든 호스트에 전송되는 방식이다.
28 | 
29 | 하지만 L2 스위치는 MAC 주소로만 동작할 뿐 상위 레이어인 3계층에서 동작하는 ip 등을 이해하지 못한다. 따라서 라우팅을 할 수 없다.
30 | 
31 | ### Layer3 스위치(라우터)
32 | 데이터를 단순전달만 하는 L2와는 달리, L3는 **라우팅 기능이 있어 외부에 연결된 포트도 데이터를 보낼 수 있다.**
33 | L2 스위치는 서로 다른 네트워크의 경우 통신이 되지 않지만, L3 스위치는 서로 다른 네트워크여도 라우팅하여 통신할 수 있다. 따라서 라우터와의 경계가 모호하다. 
34 | > 라우터와 L3 스위치와의 차이점을 많이 찾아보았지만 결론적으로 거의 같은 의미로 사용한다고 한다. 굳이 기준을 잡고 구분할 수 있겠지만 차이점이 거의 없기 때문에 같은 뜻으로 받아들여도 된다고 한다. 
35 | 
36 | ![L3](https://user-images.githubusercontent.com/43868540/104829794-a2988d00-58ba-11eb-9e89-96ef37d732b4.PNG)
37 | 
38 | > [출처](https://blog.naver.com/PostView.nhn?blogId=wjw1225&logNo=222147131756)
39 | 
40 | - 패킷의 **IP 주소**를 읽어 스위칭하고, IP가 OSI 7계층 중 3계층에 해당하기 때문에 Layer 3 스위치라 한다. 
41 | - L2 스위치에 라우팅(Routing) 기능을 추가하고 TCP/IP를 이용한다.
42 | 
43 | ### Layer4 스위치(로드밸런싱)
44 | L4 스위치는 TCP와 UDP의 헤더를 보고 포트를 분별해 적절한 서버로 패킷을 전송한다. 즉, 똑같은 IP여도 포트 번호가 다를 경우 다른 서버로 보낼 수 있다. 
45 | 그리고 그것이 FTP인가 HTTP인가 SMTP인가를 보고 어떤 것을 우선시해서 스위칭할지 판단할 수 있다. 또한, 서버나 네트워크의 트래픽을 로드밸런싱을 할 수 있다.
46 | > 로드밸런싱은 여러 대의 서버를 1대처럼 묶을 수 있는 분산기능이다.
47 | 
48 | 실제로 많은 온라인 서비스들은 대부분 최소 2개 이상의 같은 서버들로 분산처리 되게끔 구성되어있다고 한다. 이때 서비스를 분산시켜주는 장비가 L4이다. 이는 부하를 분산하기 위함도 있고 서비스가 죽는 때를 대비하기 위한 것이다. 이로 인해 서버에 트래픽 과부하를 거는 디도스 공격이 불가능해진다는 장점도 있다.
49 | 
50 | ![L4](https://user-images.githubusercontent.com/43868540/104828573-3ca60880-58ae-11eb-8ba1-5e98db78c670.PNG)
51 | 
52 | > [출처](https://klero.tistory.com/entry/L2-L3-L4-L7-%EC%8A%A4%EC%9C%84%EC%B9%98-%EA%B5%AC%EB%B6%84-%EB%B0%8F-%EA%B8%B0%EB%B3%B8%EC%A0%81%EC%9D%B8-%EC%84%A4%EB%AA%85)
53 | 
54 | - 패킷의 IP주소와 Port번호를 읽어 스위칭을 하고 Port가 OSI 7계층 중 4계층에 해당하기 때문에 Layer 4 스위치라 한다. 
55 | - L3와 같이 프로토콜을 기반으로 하며, 어플리케이션별로 우선순위를 두어 스위칭이 가능하다.
56 | - 많은 양의 트래픽을 여러 서버로 분산할 수 있다.
57 | 
58 | 
59 | ## 정리
60 | 각 어떤 계층에서 수행되는가에 따라 L2, L3 등 분류된다.
61 | 상위 레벨에서 동작하는 스위치는 자신의 하위 레벨 스위치의 기능을 다 갖고 있다. 예를 들어 L4 스위치는 L3, L2 기능도 다 수행할 수 있다.
62 | 
63 | - L2 스위치는 MAC 정보(MAC Table)를 보고 스위칭을 하는 것이다. (일반적인 스위치의 기능)
64 | - L3 스위치는 IP 정보(Routing Table)를 보고 스위칭을 하는 것이다. (라우팅 기능이 추가됨)
65 | - L4 스위치는 IP+Port(Session or Connection)를 보고 스위칭을 하는 것이다. (로드밸런싱을 위해 사용됨)
66 | 
67 | ----
68 | #### Reference
69 | - [스위치와 L2,L3,L4](https://startingpitcher.tistory.com/8)
70 | - [L1,2,3,4,7](ttps://nhj12311.tistory.com/75)
71 | 


--------------------------------------------------------------------------------
/Network/comet.md:
--------------------------------------------------------------------------------
 1 | # comet
 2 |  
 3 | ## Http 통신 방식  
 4 | 
 5 | HTTP는 클라이언트의 요청이 있을 때만 서버가 응답하여 처리한 후에 연결을 끊는 **단방향 통신**이다.  
 6 | 따라서 서버에서 클라이언트로 데이터를 전송하는 **Server Push** 가 불가능하다.   
 7 | 하지만 실시간으로 변하는 데이터를 클라이언트에게 전달하기 위해 양방향 통신의 필요성이 대두되었다.  
 8 | 이에 클라이언트가 양방향 통신이 되고 있는 것처럼 느낄 수 있도록 하는 일종의 편법, **comet** 이 고안되었다.  
 9 | 즉, comet은 실시간으로 작동하는 것이 아니라 짧은 시간 간격으로 웹페이지를 업데이트 하는 방법이다.  
10 | comet에는 `Polling`, `Long Polling`, `Streaming` 등이 있다. 
11 | 
12 | 
13 | <br/>
14 | 
15 | ## Polling  
16 | 
17 | ![polling](/assets/images/polling.png)  
18 | 
19 | Polling은 클라이언트가 서버에 **주기적으로** 요청을 보내는 방식으로, 다음과 같은 특징을 갖는다.    
20 | 
21 | * 시간마다 요청이 일괄적으로 전달된다. 
22 | * 실시간 통신이 중요한 서비스에 적합하지 않다.  
23 | 실시간으로 통신하는 느낌을 주기 위해 요청 시간의 간격을 줄일 수 있으나 이는 서버에 무거운 부하를 주게된다.  
24 | 이유는 다음의 프로세스를 반복해야 하기 때문이다. 
25 | 
26 |     ```
27 |     요청 발생 -> 연결 생성 -> HTTP header 파싱 -> 쿼리 수행 -> 응답 생성 -> 응답 전송 -> 연결 닫음
28 |     ```   
29 |     
30 | * 또한, 서버에서 보낼 데이터가 없어도 데이터를 전송해야하므로 서버의 리소스를 낭비하게 된다. 
31 | 
32 | 스포츠 경기를 시청하던 중 네이버의 실시간 중계 서비스를 확인하면, 경기 현황이 실시간으로 반영되지 않는 순간을 본 적이 있을 것이다. 바로 이와 같은 서비스를 Polling 방식을 따르는 서비스라고 할 수 있다.
33 | 
34 | 
35 | <br/>
36 | 
37 | ## Long Polling  
38 | 
39 | ![Longpolling](/assets/images/LongPolling.png) 
40 | 
41 | Long Polling은 위에서 언급한 Polling의 문제점을 해결하기 위한 방식으로, 클라이언트로부터 받은 요청을 유지하다가 데이터가 발생한 후(즉, 서버 이벤트가 발생되는 시점)에 응답을 전송하는 방식이다.  
42 | 단, 요청을 무한히 유지하는 것이 아니라 time out이 발생하면 해당 요청/응답 트랜잭션을 완료하고 연결을 새로 생성한다.   
43 | Long Polling의 특징은 다음과 같다.
44 | 
45 | * 항상 연결이 유지되어 있기 때문에 사실상 실시간 통신이 가능하다.
46 | * 데이터 이동이 빈번하지 않은 서비스에 적합하다.   
47 | Long Polling 방식의 채팅방에 1000명이 참여하고 있다고 가정해보자. 한명이 메시지를 연달아 계속해서 보낸다면, 1000명의 Request Queue가 순간적으로 쌓이게 되며 서버에 부하가 생길 수 있다.   
48 | 또한 HTTP는 header가 무거운 프로토콜이기 때문에 요청의 증가에는 많은 비용이 따른다.
49 | 
50 | <br/> 
51 | 
52 | ## Streaming
53 | 
54 | ![streaming](/assets/images/streaming.png) 
55 | 
56 | Streaming 방식은 연결을 계속 유지하고, 이벤트가 발생할 때마다 부분적인 응답으로 브라우저에 데이터를 보내는 방식이다.  
57 | 응답마다 다시 요청해야 하는 Long Polling에 비해 효율적이며, 서버의 상태 변경이 매우 잦은 경우 유리하다. 
58 | 
59 | <br/>
60 | 
61 | #### Reference
62 | 
63 | [Long Polling - Concepts and Considerations](https://www.ably.io/concepts/long-polling)  
64 | [RTCS 실시간 웹 서비스를 위한 도전](https://d2.naver.com/helloworld/1052)  
65 | [웹채팅 구현시 Long-Polling 방식과 Polling방식 선택하기](https://kuimoani.tistory.com/entry/%EC%9B%B9%EC%B1%84%ED%8C%85-%EA%B5%AC%ED%98%84%EC%8B%9C-Long-Polling-%EB%B0%A9%EC%8B%9D%EA%B3%BC-Polling%EB%B0%A9%EC%8B%9D-%EC%84%A0%ED%83%9D%ED%95%98%EA%B8%B0)
66 | 


--------------------------------------------------------------------------------
/Network/get&post.md:
--------------------------------------------------------------------------------
  1 | # GET & POST
  2 | 
  3 | GET과 POST는 HTTP를 이용해서 서버에 무언가를 전달하는 방법(method)이다.
  4 | 
  5 | <br/>
  6 | 
  7 | ## 들어가기 전에...
  8 | 
  9 | HTTP는 클라이언트와 서버가 소통하기위해 만들어진 프로토콜로, HTTP메세지를 서로 주고 받는다.
 10 | 
 11 | ![get&post](/assets/images/get&post.png)
 12 | 
 13 | <br/>
 14 | 
 15 | ## GET Method
 16 | 
 17 | GET은 서버에 있는 **정보를 조회**할때 사용된다. 따라서 전송되는 정보는 요청(request)을 위한 것이다.
 18 | 
 19 | 데이터를 Body에 담지 않고 **URL형태(쿼리 스트링)로 표현**한다. 따라서, URL형식에 맞지 않은 데이터는 인코딩하여 전달하여야 한다.
 20 | > URL은 [퍼센트 인코딩](https://ko.wikipedia.org/wiki/%ED%8D%BC%EC%84%BC%ED%8A%B8_%EC%9D%B8%EC%BD%94%EB%94%A9)을 한다.
 21 | > 예시는 다음과 같다.
 22 | > ```html
 23 | > https://ko.wikipedia.org/wiki/퍼센트_인코딩 <!-- 아래와 같이 인코딩 된다.-->
 24 | > https://ko.wikipedia.org/wiki/%ED%8D%BC%EC%84%BC%ED%8A%B8_%EC%9D%B8%EC%BD%94%EB%94%A9
 25 | > ```
 26 | 
 27 | <br/>
 28 | 
 29 | 데이터를 쿼리스트링으로 표현하여 전송하기 때문에, **body가 빈 상태**로 전송된다. 또한 헤더에 content-type이 들어가지 않는다. 
 30 | 
 31 | ```
 32 | http://example.com/date.html?key=value&key=value
 33 | ```
 34 | 
 35 | `?` 뒤에 key와 value의 쌍을 전송하고, `&`구분자를 통해 데이터를 나열한다.
 36 | 
 37 | > content-type : 데이터 설명 및 타입 명시
 38 | 
 39 | ### 특징
 40 | 
 41 | * 캐싱이 가능하다.
 42 | 
 43 | * 브라우저 기록에 남는다.
 44 | 
 45 | * 북마크 될 수 있다.
 46 | 
 47 | * 절대  민감한 데이터를 다루면 안된다.
 48 | 
 49 | * 길이 제한이 있다.
 50 | 
 51 | * 데이터 요청에 사용된다(수정불가)
 52 | 
 53 | <br/>
 54 | 
 55 | ## POST Method
 56 | 
 57 | POST는 서버의 리소스를 **생성하거나 수정**하기 위해 데이터를 보내는 것이다. **데이터는 body에 저장되어 전송**된다.
 58 | 
 59 | ```
 60 | POST /target.html HTTP/1.1
 61 | Host: example.com
 62 | Content-Type: text/html; charset=utf-8
 63 | name1=value1&name2=value2
 64 | ```
 65 | 
 66 | 헤더필드에 content-type이 들어간다.
 67 | 
 68 | ### 특징
 69 | 
 70 | * 캐싱 사용 불가
 71 | 
 72 | * 브라우저 기록에 남지 않는다.
 73 | 
 74 | * 북마크 될 수 없다.
 75 | 
 76 | * 데이터 길이제한이 없다.
 77 | 
 78 | <br/>
 79 | 
 80 | ## 언제 써야하는가?
 81 | 
 82 | ### GET은 가져오는 것
 83 | 
 84 | GET은 sql에 비유하면, SELECT적인 성향을 가진다. GET은 서버에서 데이터를 가져와서 보여주고 싶을 때 사용하는 것이다. 서버의 값이나 상태등을 바꾸지 않는다. 검색을 하거나 게시판의 글을 볼 때 주로 사용된다.
 85 | 
 86 | <br/>
 87 | 
 88 | ### POST는 수행하는 것
 89 | 
 90 | 서버의 값이나 상태를 바꾸기 위해 사용된다. 예를들어, 글쓰기를 하면 글의 내용이 서버에(DB) 저장되고, 수정을 하면 서버의 값이 수정되는 것이다.
 91 | 
 92 | <br/>
 93 | 
 94 | ### 더 나아가서
 95 | 
 96 | 기본적으로 두 방식 모두 클라이언트 측에서 볼 수 있기 때문에 보안을 위해서는 암호화 해야한다.
 97 | 
 98 | GET방식의 요청은 캐싱(데이터저장)때문에 더 빠르다.
 99 | 
100 | 하지만, 비밀번호와 같은 민감한 정보의 경우 GET방식 대신 POST를 사용하여야 한다. 정보가 URL에 그대로 드러나는 문제도 있다. 또한, get방식은 requset를 통해 보낸 parameter가 브라우저에 기록에 남아 있는 방식이다. 반면, post는 parameter가 브라우저 기록이나 웹 서버 로그에 남지 않는다.
101 | 
102 | 위와 같은 이유로 GET방식은 새로고침과 무관하지만, POST방식은 새로고침이나 뒤로가기한 뒤 페이지에 새로 접근하게되면 데이터가 다시 제출된다.
103 | 
104 | <br/>
105 | 
106 | ------
107 | 
108 | #### Reference
109 | 
110 | * <https://blog.outsider.ne.kr/312>
111 | * <https://mommoo.tistory.com/60>
112 | * <http://www.ktword.co.kr/abbr_view.php?m_temp1=4884>
113 | * <https://www.w3schools.com/tags/ref_httpmethods.asp>
114 | 


--------------------------------------------------------------------------------
/Network/로드밸런싱 & 클러스터링.md:
--------------------------------------------------------------------------------
 1 | # 로드밸런싱 & 클러스터링
 2 | 
 3 | 한 웹 사이트에 접속자가 한 두명이 아닌 수천명이 접속한다면 서버는 모든 접속자에게 응답해주려고 하지만 결국 동작을 멈추게 될 것이다. <br/>예를 들면, 선착순 이벤트에서 동시 접속자 수가 급격하게 증가했을 때 서버가 죽는 것이 이와 같은 경우다.
 4 | 
 5 | <br/>
 6 | 
 7 | ## 성능 개선 방식
 8 | 
 9 | - **`scale-up`** : 하드웨어의 성능을 높여 서버가 빠르게 동작하도록 하는 방식
10 | - **`scale-out`** : 여러 대의 서버가 나눠서 동작하도록 하여 성능을 개선하는 방식
11 | 
12 | `scale-out`방식은 `scale-up`방식에 비해 **비용이 적게 들고 여러 대의 서버 덕분에 무중단 서비스를 제공**할 수 있다.
13 | 로드밸런싱과 클러스터링은 모두 `scale-out`방식이다.
14 | 
15 | <br/>
16 | 
17 | ## 로드밸런싱
18 | 
19 | 로드밸런싱이란 트래픽이 많을 때 가상 IP를 통해 여러 서버에 접속하도록 분배하는 기능이다.
20 | 
21 | 로드밸런싱을 이용하면 **한 서버가 내려가더라도 이중화시킨 다른 서버에서 서비스를 지속하도록 할 수 있기 때문에 접속자들이 문제 없이 서비스를 이용**할 수 있다.
22 | 
23 | 로드밸런싱의 문제는 **세션(Session)** 이다.<br/>세션이 저장된 서버가 아닌 다른 서버에 접속하게 되는 경우, 해당 클라이언트의 세션이 유지되지 않기 때문이다.
24 | 
25 | 세션을 고정(session sticky)함으로써 이를 해결 할 수 있다. 이 방법으로 특정 사용자의 요청이 전달될 노드를 고정시킬 수 있다.<br/> 하지만 **고정된 세션의 노드에 장애가 발생하면 고정한 의미가 없어지기 때문에 장애가 발생하여 비활성화된 노드에 대한 고려가 필요**하다.
26 | 
27 | <br/>
28 | 
29 | ### 로드밸런서의 Server 선택 기준
30 | 
31 | ---
32 | 
33 | - **Round Robin** : 단순히 Round Robin으로 분산하는 방식이다.
34 | 
35 | - **Least Connections** : 연결 개수가 가장 서버를 선택하는 방식으로 트래픽으로 인해 세션이 길어지는 경우 권장한다.
36 | 
37 | - **Source** : 사용자의 IP를 Hashing하여 분배하는 방식으로 사용자가 항상 같은 서버로 연결되는 것을 보장한다.
38 | 
39 | <br/>
40 | 
41 | ## 클러스터링
42 | 
43 | 여러 대의 컴퓨터를 병렬로 연결하여 하나의 컴퓨터처럼 사용할 수 있게 해준다.<br/>
44 | 특정 장비에 문제가 생기거나 실행중인 애플리케이션에 문제가 발생하더라도 서비스에 영향을 미치지 않도록 해준다.
45 | 
46 | <br/>
47 | 
48 | ### 로드밸런싱과의 차이
49 | 
50 | 로드밸런싱은 한 쪽 서버에 부담이 가지 않도록 트래픽을 분산해주는 역할을 한다. <br/>반면,  클러스터링은 여러 개의 서버를 하나로 묶어 성능을 높여 많은 양의 트래픽을 처리하도록 하는 것이다.
51 | 
52 | **클러스터링은 각 노드 간의 상태를 공유하기 떄문에 클러스터링된 서버 중 하나가 죽더라도 기존의 세션 연결이 끊기지 않고 다른 서버로 `failover`된다.**
53 | 
54 | 
55 | ### 세션 클러스터링
56 | 
57 | `WAS`가 2대 이상 설치되어 있을 경우, 각각의 `WAS`가 다른 세션을 가질 수 있다. 이는 **세션에 대한 처리 불일치**가 일어날 수 있다.
58 | 
59 | 이에 따라 각 `WAS`에 대한 **세션을 하나의 세션으로 관리**하게 함으로써 새로운 `WAS`에 접속하더라도 세션에 대한 불일치를 막는다. 이를 세션 클러스터링이라고 한다.
60 | 
61 | 이외에도 `Redis`를 사용하여 세션 서버를 따로 두고 세션을 일치시키는 방법도 있다.
62 | 
63 | <br/>
64 | 
65 | ---
66 | 
67 | #### Reference
68 | 
69 | - [로드 밸런서(Load Balancer)란?](https://nesoy.github.io/articles/2018-06/Load-Balancer)
70 | - [세션 클러스터링](https://brownbears.tistory.com/168)
71 | - [로드밸런싱과 클러스터링](https://asfirstalways.tistory.com/m/320?category=656859)
72 | 


--------------------------------------------------------------------------------
/Network/사용자 인증 방식(Cookie, Session & oAuth 2.0 & JWT).md:
--------------------------------------------------------------------------------
  1 | # 사용자 인증 방식
  2 | ## 목차 
  3 | 1. 서버 기반 인증 (Cookie-Session)
  4 | 2. 토큰 기반 인증 (oAuth 2.0, JWT) 
  5 | 
  6 | ## 1. 서버 기반 인증 (Cookie-Session)
  7 | ![image](https://user-images.githubusercontent.com/43839938/80296521-f906ee00-87b6-11ea-9e6f-fbf0a1e9712c.png)
  8 | 
  9 | - 설명: 전통적인 방식이다. HTTP의 `stateless`한 속성을 보완할 필요성이 생겨서 탄생했다.
 10 | - 장점: `stateful` 유지 가능
 11 | - 단점:  서버 부하 (유저의 인증 정보를 서버측에 담아둠)
 12 | 
 13 | > `stateful`: server side 에 client와 server의 연속된 동작 상태정보를 저장하는 형태  
 14 | > `stateless`: server side 에 client와 server의 연속된 동작 상태정보를 저장하지 않는 형태
 15 | 
 16 | ## 2. 토큰 기반 인증 (oAuth 2.0, JWT)
 17 | ![image](https://user-images.githubusercontent.com/43839938/80296527-0c19be00-87b7-11ea-86b1-500f6c269339.png)
 18 | - 설명: 서버 기반 인증 방식과 달리 stateless한 방식이다. 서버 부하를 덜 수 있다.
 19 | ### (1) oAuth 2.0
 20 | > oAuth 에서 사용하는 `Refresh Token`- `Access Token` 구조
 21 | ![image](https://user-images.githubusercontent.com/43839938/80296620-c14c7600-87b7-11ea-93aa-814375724d0a.png)
 22 | 
 23 | > oAuth 2.0 동작 방식
 24 | ![image](https://user-images.githubusercontent.com/43839938/80296794-d2e24d80-87b8-11ea-97e2-514ef8fbfd23.png)
 25 | 
 26 | - 설명: `Access Token`, `Refresh Token`을 이용한 인증 방식은 한 서버에서 모두 관리하는 반면, 여기 OAuth에서는 Authorization Server에서 인증+권한 관리를 하고 Resource Server에서는 자원에 대한 관리만 한다.
 27 | - 장점: 보안성 좋다. (`Access Token`을 지속적으로 발급받아야 하므로)
 28 | - 단점: 필요한 Resource가 너무 많다. `Access Token`이 만료될 때마다 새롭게 발급하는 과정에서 생기는 HTTP 요청이 잦다.
 29 | 
 30 | > `Access Token`: API를 요청할 때 사용하는 토큰. 유효기간이 짧다.  
 31 | > `Refresh Token`: Access Token의 유효기간이 만료되면 `Access Token`을 다시 발급받기 위해 사용되는 Token. `Access Token`보다 유효기간이 길다.
 32 | 
 33 | ### (2) JWT (JSON Web Token)
 34 | - 설명: 토큰 자체가 data를 가지고 있다. 
 35 | - 장점: 토큰 기반 인증의 장점 (서버 부하 덜 수 있음)
 36 | - 단점: Packet(보내는 데이터) 양이 크다. 토큰 자체를 탈취하면 ID, PW 자체를 알 수 있다. (따라서 `HTTPS` 통신을 권장한다.)
 37 | 
 38 | ###### HTTPS 관련 자료: [HTTPS란](https://github.com/im-d-team/Dev-Docs/blob/master/Security/HTTPS%EC%99%80%20SSL.md)
 39 | 
 40 | ![image](https://user-images.githubusercontent.com/43839938/80296561-5dc24880-87b7-11ea-8a48-8e8ab99e611b.png)
 41 | 
 42 | ![image](https://user-images.githubusercontent.com/43839938/80297158-af6cd200-87bb-11ea-92f1-82cadb6c8643.png)
 43 | 사이트: https://jwt.io/
 44 | 
 45 | 1) **헤더 (Header)**
 46 | ```json
 47 | {
 48 |   "typ": "JWT",
 49 |   "alg": "HS256"
 50 | }
 51 | ```
 52 | > typ: 토큰의 타입을 지정한다. 여기서는 JWT이다.
 53 | 
 54 | > alg: 해싱 알고리즘을 지정한다. 해싱 알고리즘으로는 보통 HMAC SHA256 혹은 RSA 가 사용된다. 이 알고리즘은 토큰을 검증 할 때 사용되는 signature 부분에서 사용된다.
 55 | 
 56 | 2) **정보 (Payload)**
 57 | 
 58 | 3) **서명 (Signature)**    
 59 | 헤더(Header)의 인코딩 값과, 정보(Payload)의 인코딩 값을 합친 후 주어진 비밀키로 해쉬를 하여 생성한다.
 60 | 
 61 | 4) JWT 사용 예제
 62 | > JWT 토큰 생성
 63 | ```php
 64 | use Firebase\JWT\JWT;
 65 | 
 66 | function getJWToken($id, $pw, $secretKey)
 67 | {
 68 |     $data = array(
 69 |         'date' => (string)getTodayByTimeStamp(),
 70 |         'id' => (string)$id,
 71 |         'pw' => (string)$pw
 72 |     );
 73 | 
 74 |     return $jwt = JWT::encode($data, $secretKey);
 75 | }
 76 | 
 77 | (...)
 78 | const JWT_SECRET_KEY = "(시크릿 키 입니다.)"
 79 | 
 80 | $jwt = getJWToken($req->id, $req->pw, JWT_SECRET_KEY);
 81 | ```
 82 | > JWT 키로 decoding 하기
 83 | ```php
 84 | function getDataByJWToken($jwt, $secretKey)
 85 | {
 86 |     try{
 87 |         $decoded = JWT::decode($jwt, $secretKey, array('HS256'));
 88 |     }catch(\Exception $e){
 89 |         return "";
 90 |     }
 91 | 
 92 |     // print_r($decoded);
 93 |     return $decoded;
 94 | 
 95 | }
 96 | ```
 97 | #### Reference
 98 | - [[JWT] JSON Web Token 소개 및 구조](https://velopert.com/2389)
 99 | - [쉽게 알아보는 서버 인증 2편(Access Token + Refresh Token)](https://tansfil.tistory.com/59)
100 | - [[JWT를 구현하면서 마주치게 되는 고민들]](https://swalloow.github.io/implement-jwt)
101 | 


--------------------------------------------------------------------------------
/Node.js/nodejs의_특징.md:
--------------------------------------------------------------------------------
  1 | # Node.js의 특징
  2 | * 자바스크립트 런타임
  3 |     * 언어나 프레임워크, 라이브러리가 아니다.
  4 |     * 자바스크립트가 브라우저 환경에서 돌아가는 대신 내 컴퓨터에서 서비스 혹은 런타임으로 실행된다.
  5 | 
  6 | * V8자바스크립트 엔진을 사용한다.(크롬브라우저와 동일)
  7 | > 참고 - [Javascript_Engine](https://github.com/Im-D/Dev-Docs/blob/master/Javascript/Javascript_Engine.md)
  8 | 
  9 | * 언어 차원에서 네트워크를 지원한다.
 10 |     * 서버사이드 언어로 사용할 수 있다.
 11 | 
 12 | <br/>
 13 | 
 14 | ## 왜 사용하는가?
 15 | #### 빠르고, 효율적이고, 확장성이 아주 크다
 16 | * Event driven이기 때문에 싱글 루프에서 실행되고, non-blocking이다. 따라서 non-blocking i/o model을 가진다.
 17 | > blocking 모델에서는 하나의 스레드에 프로세스가 할당되면 끝날 때까지 기다려야 한다(sit and wait). 비동기적 작동이 안되기 때문에 요청이 발생할때마다 새로운 스레드를 생성한다. 반면, non-blocking i/o는 이벤트 루프로 처리를 하기 때문에 응답을 기다리지 않고 계속해서 요청을 보낼 수 있다.
 18 | 
 19 | #### 인기가 많다!
 20 | > [mean stack](https://en.wikipedia.org/wiki/MEAN_(software_bundle)) 혹은 mern stack의 n이 노드다!
 21 | * 리엑트, 뷰, 앵귤러 등과 자주 사용되는데, 같은 언어로 프런트와 백을 할 수 있기 때문
 22 | 
 23 | <br/>
 24 | 
 25 | ## 동작방식
 26 | Node.js는 **싱글 스레드(Single Thread)**로 동작하고, 비동기적인 **[event driven](https://terms.naver.com/entry.nhn?docId=822661&cid=50376&categoryId=50376)**방식을 사용한다.
 27 | 
 28 | 이는 자바스크립트와 같다. 자바스크립트 엔진을 사용하기 때문이다.
 29 | 
 30 | 차이점은 `setTimer()`과 같은 함수 혹은 `XHR` 등을 사용하는  대신, `EventEmitter` 클래스를 사용하여 이벤트와 리스너를 바인딩(binding) 한다.
 31 | 
 32 | 또한, node.js는 수많은 연결이 하나의 스레드를 통해서 이루어진다. **Non-blocking I/O**를 사용하기 때문이다.
 33 | 
 34 | 이때, 이벤트 루프를 이용하여 데이터 통신을 한다. 따라서, 이전의 데이터 전송의 완료여부와 상관없이 다음 작업이 진행된다.
 35 | > Event loop에 대한 내용은 [B_EventLoop](https://github.com/Im-D/Dev-Docs/blob/master/Javascript/B_EventLoop.md), [EventLoop](https://github.com/Im-D/Dev-Docs/blob/master/Javascript/EventLoop.md), [EventLoop_Advanced](https://github.com/Im-D/Dev-Docs/blob/master/Javascript/EventLoop_Advanced.md) 를 참고
 36 | 
 37 | <br/>
 38 | 
 39 | ## Node.js에 적합한 프로젝트 타입
 40 | 간단하게 요약하면 CPU intensive하지 않은 것이 적합하다.
 41 | 
 42 | 앞서 말했듯, node.js의 I/O실행은 비동기적이다. Blocking 없이 통신을 할 수 있는 것이 장점이다.
 43 | 
 44 | 하지만, 많은 CPU 사용이 요구되어 CPU의 작업 처리가 한계에 다다른다면 결국 서버가 느려질 것이다. 그렇게되면 당연히 어플리케이션이 느려진다.
 45 | 
 46 | 따라서 다음과 같은 프로젝트들이 어울린다.
 47 | 
 48 | * micro services 및 REST API
 49 | 
 50 | * 리얼타임 서비스(채팅, 라이브업데이트)
 51 | 
 52 | * CRUD Apps
 53 |   
 54 |     > 블로그나, 쇼핑카트, 소셜 네트워크 등
 55 | 
 56 | > CPU intensive하지 않은 선에서 툴이나 유틸리티도 괜찮다.
 57 | 
 58 | <br/>
 59 | 
 60 | ## NPM(Node Package Manager)
 61 | Node.js를 설치하면 NPM이 생기는데, [써드 파티](https://ko.wikipedia.org/wiki/%EC%84%9C%EB%93%9C_%ED%8C%8C%ED%8B%B0_%EA%B0%9C%EB%B0%9C%EC%9E%90) 패키지나 모듈을 설치하는데 사용된다.
 62 | 
 63 | 패키지들은 `node_modules`폴더에 저장된다.
 64 | 
 65 | 설치된 패키지나 denpendency는 `package.json`에 담긴다.
 66 | > node.js의 모듈들은 package의 dependency를 통하여 연결된다.
 67 | 
 68 | ```ps
 69 | npm init // Generates a package.json file
 70 | npm install express // installs a package locally
 71 | npm install -g nodemon // installs a package globally (-g플래그를 더해주면 된다.)
 72 | ```
 73 | 
 74 | <br/>
 75 | 
 76 | ## Modules of Node.js
 77 | 모듈은 노드의 아주 큰 부분이다.
 78 | 
 79 | * 기본적으로 node.js에 포함된 코어 모듈이 있고,
 80 | 
 81 | * NPM을 통해 받을 수 있고
 82 | 
 83 | * 내가 만들 수도 있다.
 84 | 
 85 | 변수들과 함수들과 클래스들 혹은 기타등등을 모듈에 포함시킬 수 있다.
 86 | 
 87 | 모듈은 모듈 이름을 사용하여 불러올 수 있다. 
 88 | 
 89 | 또한 경로를 적어주어서 불러올 수도 있다.
 90 | 
 91 | ```js
 92 | const path = require('path');
 93 | const myFile = require('./myFile');
 94 | ```
 95 | 
 96 | <br/>
 97 | 
 98 | ---
 99 | 
100 | #### Reference
101 | 
102 | * [Node.js Crash Course](https://www.youtube.com/watch?v=fBNz5xF-Kx4&feature=youtu.be)
103 | 


--------------------------------------------------------------------------------
/Performance/DeadLock(교착상태).md:
--------------------------------------------------------------------------------
 1 | # DeadLock(교착상태)
 2 | 
 3 | - **한정된 자원을 여러 곳에서 사용**하려고 할 때 발생한다.
 4 | 
 5 | - 어떤 프로세스가 자원을 요청 했을 때 그 시각에 그 자원을 사용할 수 없는 상황이 발생할 수 있고 그 때는 프로세스가 **대기 상태**로 들어 간다.
 6 | 
 7 | - **대기 상태로 들어간 프로세스가 실행 될 수 없는 상황**을 교착 상태라 한다.
 8 | 
 9 | <br/>
10 | 
11 | ## DeadLock의 발생 조건
12 | 
13 | DeadLock은 한 시스템 내에서 4가지 조건이 동시에 성립 할 때 발생한다. 즉, 4가지 조건 중 **하나라도 성립하지 않으면 DeadLock은 발생하지 않는다.**
14 | 
15 | - **상호배제(Mutual exclusion)** : 하나의 프로세스가 자원을 사용할 경우 다른 프로세스는 그 자원을 사용할 수 없는 것
16 | 
17 | - **점유대기(Hold and wait)** :  프로세스가 자신이 가질 수 있는 자원은 가지고 있으면서 다른 자원이 오기를 기다리고 있는 것
18 | 
19 | - **비선점(No Preemption)** : 프로세스가 어떤 자원의 사용을 끝낼 때까지 그 자원을 뺏을 수 없는 것
20 | 
21 | - **순환대기(Circular wait)** : 첫 번째 프로세스와 마지막 프로세스의 자원할당이 겹치게 되어 원형에 있는 모든 프로세스가 자원 할당을 받고자 기다리는 형태가 만들어지는 것
22 | 
23 | <br/>
24 | 
25 | ## DeadLock의 예방과 회피
26 | 
27 | ### DeadLock의 예방
28 | 
29 | ---
30 | 
31 | - **상호배제 예방** : 상호배제 사용하지 않음(**동시액세스 허락**)
32 | 
33 | - **점유대기 예방**: 프로세스가 필요로 하는 자원을 **일시에 요구/할당**
34 | 
35 | - **비선점 예방** : **자원 임시 할당 해제 및 원상 복구**
36 | 
37 | - **순환대기 예방** : 모든 자원의 **고유번호 지정**한다.
38 | 
39 | 위의 4가지 조건 중 하나라도 발생하지 않도록 시스템 차원에서 막아버리면 해결된다.
40 | 
41 | 근데 이 방법은 대부분 자원이 낭비되는 경향이 있다. 그리고 애초에 발생 가능성을 시스템 차원에서 막아버리면 성능이 나빠지거나 또 다른 문제의 원인이 될 수 있다.
42 | 
43 | ### DeadLock의 회피
44 | 
45 | ---
46 | 
47 | 교착상태의 발생 조건은 놔두고, **발생을 막는 알고리즘을 적용**해서 해결하는 방법이다.
48 | 
49 | 대표적으로 **은행원 알고리즘**이 있다.
50 | 
51 | **은행원 알고리즘(Banker's Algorithm)** 은 프로세스가 자원을 요구할 때 시스템이 자원을 할당한 후 안정 상태로 남아있는지를 사전에 검사한 후 **안정 상태라면 자원을 할당**하는 방식이다.
52 | 
53 | 만약, 안정 상태가 아니라면 **다른 프로세스들이 점유한 자원을 해제할 때까지 대기**한다.
54 | 
55 | 1. 자원 상황와 자원 종류의 최대 수를 파악.
56 | 
57 | 2. 프로세스가 자원 할당 요구.
58 | 
59 | 3. 시스템 상태를 파악 후 자원 할당 여부를 결정.
60 | 
61 | 4. 안정 상태라면 할당 아니라면 대기.
62 | 
63 | <br/>
64 | 
65 | #### 은행원 알고리즘의 자료 구조
66 | 
67 | - Available[n] : 자원 n의 사용 가능 개수.
68 | 
69 | - Max[m,n] : 프로세스 m 의 자원 n의 최대 요구 개수 
70 | 
71 | - Allocation[m,n] : 프로세스 m 에 할당된 자원 n의 개수
72 | 
73 | - Need[m,n] : 프로세스 m이 추가적으로 필요로 하는 자원 n의 개수
74 | 
75 | <br/>
76 | 
77 | ---
78 | 
79 | #### Reference
80 | 
81 | - [운영체제 - 교착상태, 기아상태, 은행가 알고리즘](https://m.blog.naver.com/PostView.nhn?blogId=dong5053&logNo=220717510273&proxyReferer=https%3A%2F%2Fwww.google.com%2F)
82 | - [DeadLock 발생 조건 4가지 및 해결 방법](https://blog.lael.be/post/1304)
83 | 


--------------------------------------------------------------------------------
/Performance/HTTP2.0의 필요성.md:
--------------------------------------------------------------------------------
 1 | # HTTP2.0의 필요성
 2 | 
 3 | ## HTTP/1.1
 4 | 
 5 | HTTP/1.1의 동작 방식은 간단하다. Connection하나 당 하나의 요청만 처리한다. 따라서 **동시 전송이 불가능하고 요청과 응답이 순차적으로 처리된다.** 처리할 리소스(img, css, script)가 많아질수록 Latency(대기시간)은 길어지게 되고 이는 치명적이다.
 6 | 
 7 | <br/>
 8 | 
 9 | ### Header와 3-way Handshake의 반복
10 | 
11 | ---
12 | 
13 | HTTP/1.0의 또 다른 문제로는 매 **Connection마다 중복된 헤더 요청이 일어나고, 매 요청마다 3-way Handshake가 반복적으로 일어난다.** Header가 Body보다 무거운 경우가 발생할 수 있으며, `3-way Handshake`가 반복적으로 발생하면 `RTT(Round Trip Time)`이 증가하게 되고 성능이 저하된다.
14 | 
15 | <br/>
16 | 
17 | ## 성능 향상
18 | 
19 | ### Pipelining
20 | 
21 | ---
22 | 
23 | 위에서 설명한 HTTP/1.1의 단점인 하나의 Connection 당 하나의 처리만 가능한 것을 보완해 **하나의 Connection에 다수의 리소스를 요청할 수 있는 기법으로서 `Pipelining`이 있다.**
24 | 
25 | 하지만 만약 첫 번째 리소스의 응답 시간이 길어지게 되면 응답 처리가 완료되기 전까지 나머지 리소스의 요청은 대기 상태에 빠진다. 이는 `Pipelining`의 문제이며 이를 **HOLB(Head of Line Blocking)**라고한다.
26 | 
27 | <br/>
28 | 
29 | ### Image Spriting(CSS Spriting)
30 | 
31 | ---
32 | 
33 | Image Spriting은 이미지 여러 개를 하나로 만들고 `background-position` 속성을 이용해 필요한 부분의 이미지만 보여준다. 즉, 해당 이미지의 좌표 값을 지정해 렌더링한다.
34 | 
35 | 이미지의 갯수만큼 HTTP 요청을 했던 방식을 **한 번의 요청으로 줄일 수 있어** 렌더링 속도가 향상될 수 있다.
36 | 
37 | ```css
38 | #spriteImg span {
39 |   background: url(images/buttons-bg.png) no-repeat;
40 | }
41 | 
42 | #spriteImg #profile span {background-position: 0 0;}
43 | #spriteImg #github span {background-position: 0 -15px;}
44 | ```
45 | 
46 | <br/>
47 | 
48 | ### 도메인 샤딩(Domain Sharding)
49 | 
50 | ---
51 | 
52 | **`도메인 샤딩`은 여러 개의 서브도메인을 생성하여 리소스를 병렬로 가져온다. 기본적으로 HTTP/1.1에서는 도메인 당 동시 요청의 갯수가 제한되기 때문에 이는 해결책이 될 수 있다.** 
53 | 
54 | 하지만, 각 하위 도메인의 DNS 조회를 하고 이는 시간, CPU 전력을 생각보다 많이 소모하게 된다. 또한 현재 많은 모바일 브라우저가 `Piplining`을 구현하고 있기 때문에 근본적인 해결책은 될 수 없다. 
55 | 
56 | 
57 | ### Minification
58 | 
59 | 리소스의 용량을 줄이기 위해 CSS, Script 코드를 축소하여 적용하는 방식이다.
60 | 
61 | 
62 | ## HTTP2.0
63 | 
64 | 위의 여러 방법들이 있지만 분명 한계가 존재하기 때문에 HTTP2.0이 필요해졌고 이에 대한 설명은 [HTTP2.0과 Web Socket](https://github.com/Im-D/Dev-Docs/blob/master/Browser/HTTP2_Websocket.md)에서 대체한다.
65 | 
66 | ---
67 | 
68 | #### Reference
69 | 
70 | - [나만 모르고 있던 - HTTP/2](https://www.popit.kr/%EB%82%98%EB%A7%8C-%EB%AA%A8%EB%A5%B4%EA%B3%A0-%EC%9E%88%EB%8D%98-http2/)
71 | - [도메인 샤딩](https://wonism.github.io/domain-sharding/)


--------------------------------------------------------------------------------
/Performance/Throttling vs Debouncing.md:
--------------------------------------------------------------------------------
 1 | ## 쓰로틀링 vs 디바운싱
 2 | 
 3 | 함수를 호출할 때 호출이 너무 많이 되어 과부화 됨을 방지하기 위한 기술이다.
 4 | 
 5 | 함수 호출이 잦은 예로는 브라우저의 이벤트가 있다. `onScroll` 이나 `onChange` 와 같은 이벤트의 콜백으로 함수를 호출하는 경우 굉장히 많은 호출이 발생할 수 있다.
 6 | 
 7 | infinite scroll 이나 자동완성 기능의 경우 사용자의 특정 이벤트에 따라 비동기 콜백을 호출하는 방식이다. 이 경우 이벤트가 매우 빈번하게 일어나며 많은 호출을 제어하지 않으면 브라우저가 버티지 못할 것이다. 이 때 사용하는 것이 쓰로틀링과 디바운싱이다.
 8 | 
 9 | ### 쓰로틀링(Throttling)
10 | 
11 | Throttle 은 정해진 시간동안 특정 행위를 한 번만 호출하도록 하는 것이다. 예를 들어 스크롤 행위가 1 초에 500 번이 발생한다면 이를 0.2 초에 한 번만 실행하게 만들 수 있다. 
12 | 
13 | Throttle 처리가 되지 않은 경우 콜백이 500 번 발생한다. 하지만 Throttle 처리가 된다면 5 번만 실행되게 만드는 기술이다.
14 | 
15 | 스크롤 이벤트의 경우 작은 움직임에도 엄청나게 많은 이벤트가 발생한다. 따라서 1 초 미만으로 쓰로틀링을 하여 같은 동작의 여러번 호출을 1 번으로 제어하는 것이 좋다.
16 | 
17 | ```js
18 | var timer;
19 | document.querySelector('#input').addEventListener('input', function (e) {
20 |     // 1. timer 값이 undefined니까 if문 실행
21 |     if (!timer) {
22 |         // 2. timer 에 time함수 설정
23 |         timer = setTimeout(function () {
24 |             // 3. 설정시간에 맞춰 timer 초기화 및 함수 실행
25 |             timer = null;
26 |             console.log('비동기 요청', e.target.value);
27 |         }, 2000);
28 |     }
29 | });
30 | ```
31 | 
32 | ### 디바운싱(Debouncing)
33 | 
34 | Debounce 는 한 행위를 여러 번 반복하는 경우, 마지막 행위 이후 특정 시간이 흐른 뒤에 콜백을 호출하도록 하는 방식이다. 자동완성 즉 autocomplete 를 떠올리면 편하다.
35 | 
36 | input 의 `onChange`가 일어나면 callback 으로 AJAX 를 이용해 관련 데이터를 긁어온다. 그런데 사용자의 모든 입력에 AJAX 호출을 한다면 브라우저가 견디지 못할 것이다. 
37 | 그래서 일정시간동안 Timer 를 만든다. 이 타이머의 시간동안 입력이 발생해 변경이 일어나면 Timer 를 초기화 한다. 
38 | 입력이 멈추어 Timer 가 다 되면 AJAX 를 호출한다.
39 | 
40 | ```js
41 | var timer;
42 | document.querySelector('#input').addEventListener('input', function (e) {
43 |     // 1. timer 값이 undefined니까 if문 실행
44 |     if (timer) {
45 |         // 3-1. setTimeout이 끝나기 전에 다시 이벤트 실행 시 time함수 클리어 (이벤트 호출 시 마다 반복)
46 |         clearTimeout(timer);
47 |     }
48 |     // 2. 함수 할당
49 |     // 3-2. 함수 할당 (이벤트 호출 시 마다 반복)
50 |     timer = setTimeout(function () {
51 |         console.log('비동기 요청', e.target.value);
52 |     }, 2000);
53 |     // 4. 설정 시간 지나면 함수 종료
54 | });
55 | ```
56 | 
57 | [Lodash](https://lodash.com/) 와 [Underscore](https://underscorejs.org/)에는 해당 기능들이 구현되어 있다.
58 | 
59 | ---
60 | 
61 | #### 🙏Reference
62 | 
63 | - [[JS] 쓰로틀링(Throttling)과 디바운싱(Debouncing)](https://jm-web.tistory.com/33)
64 | - [zerocho blog - 쓰로틀링과 디바운싱](https://www.zerocho.com/category/JavaScript/post/59a8e9cb15ac0000182794fa)
65 | - [CSS-Tricks 의 Throttling 과 Debouncing](https://css-tricks.com/debouncing-throttling-explained-examples/) => 예시가 구현되어 있음
66 | 


--------------------------------------------------------------------------------
/Performance/requestAnimationFram(rAF).md:
--------------------------------------------------------------------------------
 1 | # requestAnimationFrame(rAF)
 2 | 
 3 | 사용자들이 서비스를 선택하는데 있어서 기준은 다양하다. 그 중에서 하나는 인터렉션(Interaction)이다. 인터렉션은 상호 작용이라는 사전적 뜻을 가지며, 서비스 차원에서는 **사용자가 제품이나 서비스를 사용하면서 상호간 작용하는 것**이라는 넓은 의미를 가진다.
 4 | 
 5 | 이에 서비스를 운영하는 기업들은 부드러운 인터렉션을 만들어내기 위해서 노력을 하고 있다.
 6 | 
 7 | 개발자의 입장에서 생각을 하면 부드러운 인터렉션을 만들어내기 위해서 프레임 수에 맞도록 시각적인 효과를 만들어야 한다.
 8 | 
 9 | 오늘날의 기기들은 시각적인 효과를 위해서 초당 60번 화면을 다시 그린다.(요즘에는 주사율이 좋은 모니터들이 많다.) 그러므로 60개 화면안에서 시각적인 효과를 표현해야한다.
10 | 
11 | 초당 60개의 프레임을 렌더링해야한다는 말은 1프레임이 약 16ms(1000ms/60frames)라는 것을 의미한다. 즉 부드러운 화면을 위해서 우리는 16ms미만으로 새로 보여줄 화면을 만들면 된다.
12 | 
13 | 우리가 16ms안에 화면을 만들기 전에 렌더링 파이프라인에 대해서 알아야 한다.
14 | 
15 | ![Pipeline](https://user-images.githubusercontent.com/24274424/69901968-b12c9800-13cb-11ea-9e6f-26ad0167ad53.png)
16 | 출처 : https://developers.google.com/web/fundamentals/performance/rendering/?hl=ko
17 | 
18 | > 참고: [웹 브라우저의 작동 원리](https://github.com/Im-D/Dev-Docs/blob/master/Browser/%EC%9B%B9%20%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EC%9D%98%20%EC%9E%91%EB%8F%99%20%EC%9B%90%EB%A6%AC.md)
19 | 
20 | - 애니메이션 및 기타 작업들을 수행하는 `Javascript`
21 | - CSS 규칙을 어떤 요소에 적용할지 계산하는 `Style`
22 | - 브라우저가 요소에 어떤 규칙을 적용할지 알게 되면 화면에서 얼마나 공간을 차지하고 어디에 배치되는지 계산하는 `Layout(reflow)`
23 | - 픽셀을 채우는 `Paint(redraw)`
24 | - 이러한 작업들이 개별적인 레이어에서 진행되고 이를 합치는 `Composite`
25 | 
26 | 때에 따라 다르지만 기본적으로는 한 번의 화면을 그리기 위해서 위와 같은 과정을 수행한다. 
27 | 
28 | 이전에는 애니메이션을 구현하는데 있어서 `setTimeout()` 또는 `setInterval()`을 사용되었다. 하지만 주어진 시간내에 동작을 할 뿐이지 위에서 언급한 프레임은 고려되지 않는다.
29 | 
30 | 이에 사용되는 것이 `requestAnimationFrame()`이다.
31 | 
32 | 이 메소드는 실제 화면이 갱신되어 표시되는 주기에 따라 함수를 호출해주기 때문에 Callback이 프레임 시작시 실행되는 것이 보장된다.
33 | 
34 | Callback의 수는 보통 1초에 60회지만, 일반적으로 대부분의 브라우저에서는 W3C 권장사항에 따라 그 수가 디스플레이 주사율과 일치하게 된다. 
35 | 
36 | 대부분의 최신 브라우저에서는 성능과 배터리 수명 향상을 위해 `requestAnimationFrame()` 호출은 백그라운드 탭이나 hidden `<iframe>`에서 실행이 중단된다.
37 | 
38 | ## 예시
39 | 
40 | Jbee님 포스팅 중 [스크롤 이벤트 최적화](https://jbee.io/web/optimize-scroll-event/)를 보면 `rAF`를 이용하여 스크롤 이벤트를 구현하는 방식을 살펴볼 수 있는데 간단히 보면 다음과 같다.
41 | 
42 | ```js
43 | function rAFScroll(callback) {
44 |   let tick = false
45 | 
46 |   return function trigger() {
47 |     if (tick) {
48 |       return;
49 |     }
50 | 
51 |     tick = true
52 |     return requestAnimationFrame(function task() {
53 |       tick = false
54 |       return callback();
55 |     })
56 |   }
57 | }
58 | ```
59 | 
60 | `trigger`함수를 보면 `tick`의 값이 `false`일 경우에만 `requestAnimationFrame`의 콜백이 실행된다. <br/>즉, **콜백 함수(`callback`)가 `rAF`에 의해 브라우저가 최적화된 상태에서만 `tick`의 값이 `false`가 되고 실행**된다. 순차적으로 정리하면 다음과 같다.
61 | 
62 | 1. `rAF`의 콜백 함수인 `task`함수가 `animation frame`에 들어간다.
63 | 2. `tick`의 값이 `true`라면 `trigger`함수가 호출되어도 콜백 함수가 실행되지 않는다.
64 | 3. `task`함수가 실행되면서 `tick`이 `false`가 되면 다시 콜백 함수가 실행될 수 있는 환경이 된다.
65 | 
66 | 이처럼 쓰로틀링을 사용하지 않고 `rAF`을 사용하여 이벤트 최적화가 가능하며 `rAF`는 애니메이션의 최적화에도 많이 사용되는 API이기 때문에 잘 알아두는게 좋다.
67 | 
68 | ## 브라우저 호환성
69 | 
70 | ![image](https://user-images.githubusercontent.com/24274424/69902311-539a4a80-13cf-11ea-85b8-774690c747b0.png)
71 | 
72 | ---
73 | 
74 | #### Reference
75 | 
76 | - [스크롤 이벤트 최적화](https://jbee.io/web/optimize-scroll-event/)
77 | - [requestAnimationFrame() 개념 정리하기](https://fullest-sway.me/blog/2019/01/28/requestAnimationFrame/)
78 | - [Deview 2018 - 웹 성능 최적화에 필요한 브라우저의 모든 것](https://www.slideshare.net/deview/125-119068291)


--------------------------------------------------------------------------------
/Performance/서버 사이드 렌더링(SSR).md:
--------------------------------------------------------------------------------
 1 | # 서버 사이드 렌더링(SSR)
 2 | 
 3 | <br/>
 4 | 
 5 | ## SPA의 등장
 6 | 
 7 | 모바일 웹이 등장하고 활성화되기 시작하면서 일반 데스크탑보다 성능이 낮은 모바일에서도 웹 페이지를 출력할 일이 늘었고 이에 따라 SPA가 등장하게 되었다.
 8 | 
 9 | **SPA(Single Page web Application)는 최초 한 번 페이지를 로딩한 뒤 데이터가 변하면 변한 부분만 다시 로드하는 방식의 애플리케이션**을 말한다.
10 | 
11 | <br/>
12 | 
13 | ## 클라이언트 사이드 렌더링 vs 서버 사이드 렌더링
14 | 
15 | ### 클라이언트 사이드 렌더링
16 | 
17 | ---
18 | 
19 | - **일관성 있는 코드의 작성**
20 | 
21 | **서버에서는 JSON만 넘겨주고 html을 그리는 역할이 클라이언트 측으로 넘어가면서 JS를 이용해 화면을 그리게 되었다.**
22 | 
23 | 클라이언트 사이드 방식을 통해 클라이언트 측에서는 좀 더 편하게 일관성 있는 코드를 작성할 수 있다.
24 | 
25 | 하지만, 클라이언트 사이드 렌더링 방식에는 문제가 존재한다.
26 | 
27 | - **초기 구동 속도의 증가**
28 | 
29 | 페이지를 그리고, JS 파일을 다운받고, 그리고 JS가 화면을 그리는 시간이 모두 지나야 화면이 사용자에게 보여진다. 즉, **초기 구동 속도가 낮아 사용자 경험을 떨어트리게 된다.** <br/> 비록, 초기 구동 속도가 느리지만 초기 화면을 로드한 후 화면을 데이터의 변화에 따라 그릴 때는 빠른 인터렉션을 보인다.
30 | 
31 | - **검색 엔진 최적화(Search Engine Optimization, SEO)**
32 | 
33 | 클라이언트 사이드 렌더링 방식에서는 초기 html에는 컨텐츠가 없는 **빈 껍데기**인 상태이다.
34 | 
35 | 모든 검색 엔진이 그런 것은 아니지만, **검색 엔진에서 컨텐츠를 검색할 때 JS 파일의 내용은 읽어들이지 못하기 때문에** B2C를 목적으로 하는 웹 사이트의 경우에는 치명적인 문제가 될 수 있다.
36 | 
37 | ### 서버 사이드 렌더링
38 | 
39 | ---
40 | 
41 | 서버 사이드 렌더링의 경우, 클라이언트 사이드와 반대로 생각하면 편하다.
42 | 
43 | 서버 사이드 렌더링이란 개념은 **서버에서 미리 페이지를 그려 클라이언트에 보낸다.**
44 | 
45 | 이 때 **가상DOM을 활용하여 바뀐 부분만 바꿔주는 등 클라이언트에서의 부하는 최소화**한다.
46 | 
47 | - **초기 구동 속도의 감소**
48 | 
49 | 위에서 말했듯이 서버에서 미리 페이지를 그려 클라이언트에 보내기 때문에 사용자 경험이 개선 되고 사용자 입장에서는 화면이 바뀌는 과정을 보지 않고 **최초에 완성된 화면을 볼 수 있게 된다.**
50 | 
51 | - **검색엔진 최적화(Search Engine Optimization, SEO)**
52 | 
53 | 이또한 마찬가지로 서버에서 컨텐츠를 포함하여 화면을 그리고 클라이언트 측으로 넘겨주기 때문에 **검색엔진에서는 컨텐츠를 포함한 내용을 검색**하게 된다. 즉, 클라이언트 사이드 렌더링에서 존재했던 SEO 문제를 해결할 수 있다.
54 | 
55 | - **복잡도와 서버의 부하 증가**
56 | 
57 | React를 쓴다고 가정했을 때 서버 쪽에서 JSX를 사용할 수 있도록 빌드하거나 변환하는 과정이 필요해진다. 최초 세팅 시 어려움이 증가하게 되는 것이다. 물론 이러한 러닝 커브를 줄이기 위해 React에서는 `Next.js`와 Vue에서는 `Nuxt.js`와 같은 **서버사이드 라이브러리**가 존재한다.
58 | 
59 | 그리고 클라이언트측에서의 부하가 없어진 것이 아닌 서버로 넘어간 것이기 때문에 써드 파티 라이브러리를 통해 비동기식으로 렌더링이 발생하도록 만들어주거나 웹 서버와 API 서버를 분리하는 등의 작업이 필요하다.
60 | 
61 | <br/>
62 | 
63 | ---
64 | 
65 | #### Reference
66 | 
67 | - [카카오페이지 웹 React 포팅 후기](https://medium.com/@ljs0705/%EC%B9%B4%EC%B9%B4%EC%98%A4%ED%8E%98%EC%9D%B4%EC%A7%80-%EC%9B%B9-react-%ED%8F%AC%ED%8C%85-%ED%9B%84%EA%B8%B0-76402cc5e031)
68 | - [서버사이드 렌더링 그리고 클라이언트 사이드 렌더링](http://asfirstalways.tistory.com/244)
69 | - [JSX — React JS+ Java server side rendering (SSR) — 2018](https://codeburst.io/jsx-react-js-java-server-side-rendering-ssr-2018-cf3aaff7969d)
70 | - [서버사이드 렌더링](https://velopert.com/3425)
71 | 


--------------------------------------------------------------------------------
/Performance/점진적향상_우아한하향.md:
--------------------------------------------------------------------------------
 1 | # 점진적 향상, 우아한 하향
 2 | 
 3 | 2가지 개발접근법이 있다. 우아한 하향과 점진적인 향상.<br/>
 4 | 간단히 정리하자면 다음과 같이 정의할 수 있다.
 5 | <br/>
 6 | 
 7 | ## 우아한 하향(Graceful degradation)
 8 | 
 9 | `Graceful Degradation`, 이 자체는 사실 단어만 보면 크게 와닿지 않는다.
10 | 이는 기능을 제대로 구현하면서, 기술적인 이유나 Device의 호환성 여부에 의해 해당 기능을 제공받지 못하는 사용자에게 다른 버전의 대체 기능을 제공한다.
11 | 혹은, 단순히 `맥 OS에서는 해당 기능을 제공할 수 없기 때문에 Windows 컴퓨터를 이용해주세요.`와 같은 문구를 제공한다.
12 | 
13 | 정리하면 다음과 같다.
14 | 
15 | - 원하는 기능을 갖는 또다른 버전을 제공하거나, 사용자가 제품의 결점이 사용성을 보장하기 위한 안전 조치때문이라는 것을 인지하도록 만드는 것.
16 | - 최신 기술 기반 또는 기기에서 동작하는 기능을 만들고 나서 오래된 기술 기반 혹은 기기에서도 유사한 성능으로 동작하도록 조치하는 것.
17 | - 사용자들의 기기를 위해 별도의 버전을 만들어 놓는 것.
18 | 
19 | `Graceful Degradation`이 유용한 경우가 있다.
20 | 
21 | - 오랜된 제품을 새로 개발하기엔 시간이 부족하고 방법과 영향도를 파악할 수 없는 경우.
22 | - 일반적으로 `Graceful Degradation`을 통해 개발이 진행되면 성능이 더 좋을 확률이 높기 때문에 수행 속도에 민감한 애플리케이션의 경우.(ex, rAF vs jQuery .animate)
23 | 
24 | <br/>
25 | 
26 | ## 점진적 향상(Progressive enhancement)
27 | 
28 | `Progressive Enhancement`는 `Graceful Degradation`과 반대로 생각하면 된다.
29 | 웹의 관점에서 봤을 때 이에는 몇 가지 원칙이 있는데 다음과 같다.
30 | 
31 | - 컨텐츠가 모든 브라우저에서 표현.
32 | - 기능이 모든 브라우저에서 사용.
33 | - `Semantic Markup`으로 표시.(HTML5)
34 | - 레이아웃의 향상은 `CSS`로 처리.
35 | - 동작의 향상은 `unobtrusive javascript`로 처리.
36 | - 사용자가 브라우저 설정을 원하는대로 변경해도 기능이 잘 동작함.
37 | 
38 | > unobtrusive javascript란 필수적인 기능들을 HTML만으로 최대한 처리하고 그 위에 JS를 이용해 기능을 추가한다는 의미.
39 | 
40 | 몇 가지 특징을 정리해보면 다음과 같다.
41 | 
42 | - 사용가능한 기능을 바탕으로, 향상된 기능을 적용하기 전에 테스트를 통해 풍부한 사용자 경험을 **하나씩 증가**시키는 것이다.
43 | - 많은 테스트를 통해 말그대로 **기능을 점진적으로 향상**시키는 것.
44 | - **기초부터 차곡차곡** 쌓아서 발전해 나가는 방법
45 | 
46 | 해당 개발접근법을 적용한 대표적인 예로 `jQuery`가 있다. HTML의 기능을 충분히 활용하도록 설계되었기 때문에 다른 JS의 사용을 최소화할 수 있다고 설명하고 있다.
47 | 
48 | 결국, `jQuery`도 JS기 떄문에 살짝 모순적인 얘기일 수 있다.
49 | 하지만, `jQuery`가 크로스 브라우징을 해결할 수 있는 대표적인 방법 중 하나라는 것은 이를 방증한다고 볼 수 있을 것 같다.
50 | 
51 | 보통 우리는 `Graceful Degradation`을 많이 봐왔을 것이다. 브라우저가 다양화되고 기술의 지원 여부가 브라우저에 따라 상이하기 때문이다.
52 | 하지만, 어떻게 보면 `Progressive Enhancement`접근법을 통해 개발된 애플리케이션의 경우, 사용자가 인지할 수 없기 때문에 전자가 더 많다고 보기도 어려울 수 있다.
53 | 
54 | <br/>
55 | 
56 | ---
57 | 
58 | #### Reference
59 | 
60 | - [적절한 낮춤 대 점진적 향상](http://www.clearboth.org/51_graceful_degradation_versus_progressive_enhancement/)
61 | - [Progressive Enhancement와 Graceful Degradation](https://m.blog.naver.com/PostView.nhn?blogId=sef16&logNo=70164174952&proxyReferer=https%3A%2F%2Fwww.google.com%2F)
62 | - [W3C - Graceful degradation versus progressive enhancement](https://www.w3.org/wiki/Graceful_degradation_versus_progressive_enhancement)
63 | 


--------------------------------------------------------------------------------
/React/Element와 Component.md:
--------------------------------------------------------------------------------
  1 | # Element와 Component
  2 | 
  3 | <br/>
  4 | 
  5 | ## Element
  6 | 
  7 | `React`에서 `element`는 일반 객체(Plain Object)이다. 따라서 생성하는데 큰 어려움이 없이 생성이 가능하다.<br/>
  8 | 단, 한 번 생성된 `element`는 변경불가능하다. 즉, `element`를 생성한 이후에는 해당 엘리먼트의 자식이나 속성을 변경할 수 없다.
  9 | 
 10 | ```js
 11 | const element = React.createElement(
 12 |   'div',
 13 |   {id: 'login-btn'},
 14 |   'Login'
 15 | )
 16 | ```
 17 | 
 18 | `React.createElement()`함수는 아래와 같이 일반 객체를 반환한다.
 19 | 
 20 | ```js
 21 | {
 22 |   type: 'div',
 23 |   props: {
 24 |     children: 'Login',
 25 |     id: 'login-btn'
 26 |   }
 27 | }
 28 | ```
 29 | 
 30 | ### React Element 렌더링과 업데이트
 31 | 
 32 | ---
 33 | 
 34 | `React Element`를 렌더링하기 위해서는 `element`를 생성하고 이를 `ReactDOM.render()`로 `root DOM Node`와 생성한 `element`를 넘기면 된다.
 35 | 
 36 | ```js
 37 | const element = React.createElement(
 38 |   'div',
 39 |   {id: 'login-btn'},
 40 |   'Login'
 41 | );
 42 | ReactDOM.render(element, document.getElementById('root'));
 43 | ```
 44 | 
 45 | [React 공식 문서 - Rendering Element](https://codepen.io/pen?&editable=true&editors=0010)
 46 | 
 47 | 
 48 | `React Element`는 불변 객체기 때문에 변경할 수 없다. 따라서 업데이트하기 위해서는 새로운 `element`를 생성하여 `ReactDOM.render()`로 넘겨주면 된다.
 49 | 
 50 | [React 공식 문서 - Update Element](https://codepen.io/pen?&editable=true&editors=0010)
 51 | 
 52 | <br/>
 53 | 
 54 | ## Component
 55 | 
 56 | `React`에서 `Component`는 함수와 비슷하다고 보면 된다.
 57 | 
 58 | ```js
 59 | const Button = ({ onLogin }) =>
 60 |   <div onClick={onLogin} />
 61 | ```
 62 | 
 63 | 위와 같이 `Component`를 생성하면 `JSX`에서는 이를 아래와 같이 `transpile`한다.
 64 | 
 65 | ```js
 66 | const Button = ({ onLogin }) => React.createElement(
 67 |   'div',
 68 |   { onClick: onLogin },
 69 |   'Login'
 70 | )
 71 | ```
 72 | 
 73 | [React 공식 문서 - Component Rendering](https://ko.reactjs.org/redirect-to-codepen/components-and-props/rendering-a-component)
 74 | 
 75 | <br/>
 76 | 
 77 | ### Class Component vs Function Component
 78 | 
 79 | ---
 80 | 
 81 | `Component`를 생성하는 방법에는 2가지가 있는데 첫 번째로 가장 간단한 방법은 `JS`함수를 작성하면 된다.
 82 | 
 83 | ```js
 84 | //JS function 생성
 85 | function HelloWorld(props) {
 86 |     return <h1>Hello World {props.name}</h1>;
 87 | }
 88 | ```
 89 | 
 90 | 또 다른 방법은 `ES6`의 `class`문법을 사용하여 생성하는 것이다.
 91 | 
 92 | ```js
 93 | //ES6 class 사용
 94 | class HelloWorld extends React.Component {
 95 |   render() {
 96 |     return <h1>Hello World {props.name}</h1>;
 97 |   }
 98 | }
 99 | ```
100 | 
101 | > 만약, `Component`가 `state`나 `LifeCycle Method`가 필요하다면 `class Component`를 사용하면 되고, 그게 아니라면 `function Component`를 사용하면 된다.
102 | 
103 | ---
104 | 
105 | #### Reference
106 | 
107 | - [sudheerj/reactjs-interview-questions](https://github.com/sudheerj/reactjs-interview-questions#what-is-the-difference-between-element-and-component)
108 | - [react Docs - 엘리먼트 렌더링](https://ko.reactjs.org/docs/rendering-elements.html)
109 | - [react Docs - Component와 Props](https://ko.reactjs.org/docs/components-and-props.html)
110 | 


--------------------------------------------------------------------------------
/React/ImmutableState.md:
--------------------------------------------------------------------------------
 1 | ### React의 상태 불변성
 2 | 
 3 | `react`와 `redux`의 공식 문서를 읽다 보면 `Immutability`를 강조하는 대목을 종종 볼 수 있다. 
 4 | 왜 불변성(Immutability)를 유지해줘야 할까?
 5 | 
 6 | 불변성을 지키지 않으면 우리는 컴포넌트를 최적화 할 수 없다.
 7 | 
 8 | 리액트가 컴포넌트를 렌더링하는 과정을 살펴보자.
 9 | 
10 | > 1. setState를 호출 (혹은 부모로부터 props를 전달 받음)
11 | > 2. shouldComponentUpdate를 실행했는데 false를 리턴하면 여기서 멈추고, true를 리턴하면 다음 단계로 이동
12 | > 3. 가상 DOM과 실제 DOM을 비교해서 변경사항이 있으면 화면을 다시 그린다
13 | 
14 | 핵심은 2번에 있다. 다음과 같은 2개의 상태를 비교한다고 가정해보자.
15 | 
16 | ```js
17 | const array = [1,2,3,4];
18 | const sameArray = array;
19 | sameArray.push(5);
20 | 
21 | console.log(array !== sameArray); // false
22 | ```
23 | 
24 | ```js
25 | const array = [1,2,3,4];
26 | const differentArray = [...array, 5];
27 | console.log(array !== differentArray); // true
28 | ```
29 | 첫 번째 코드의 `array`와 `sameArray`변수가 참조하고 있는 배열의 주소 값은 서로 같다. 하지만, 두 번째 코드의 각각의 배열은 다른 레퍼런스를 가지기 때문에 비교했을 때 다르다는 결과 값이 나오게 된다.
30 | 이와 같이 불변성을 유지하여 코드를 작성하면 각 객체의 값이 아닌 레퍼런스 값만 비교를 해주면 된다.
31 | 
32 | 즉, `shouldComponentUpdate`내의 코드는 한 줄이면 컴포넌트를 최적화할 수 있게 된다.
33 | 
34 | 하지만, 불변성을 유지하며 코드를 작성하다보면 상태 업데이트 로직이 복잡해질 수 있다.
35 | 
36 | ```js
37 | state = {
38 |     where: {
39 |         are: {
40 |             you: {
41 |                 now: 'faded',
42 |                 away: true // 이 부분을 바꾸고 싶다
43 |             },
44 |             so: 'lost'
45 |         },
46 |         under: {
47 |             the: true,
48 |             sea: false
49 |         }
50 |     }
51 | }
52 | ```
53 | 
54 | ```js
55 | const { where } = this.state;
56 | this.setState({
57 |     where: {
58 |         ...where,
59 |         are: {
60 |             ...where.are,
61 |             you: {
62 |                 ...where.are.you,
63 |                 away: false
64 |             }
65 |         }
66 |     }
67 | });
68 | ```
69 | 
70 | 위의 예시만 봐도 충분히 복잡해지는 것을 볼 수 있다. 이런 상태 업데이트 로직을 편하게 해주는 대표적인 라이브러리가 우리가 `React`를 사용하면서 패턴 처럼 많이 사용해왔던 `Immutable.js`이다. 
71 | 
72 | 정리하자면, React의 상태는 컴포넌트 최적화를 위해 불변성을 유지해야하며 이를 편하게 하기 위해 `Immutable.js`같은 불변 객체를 반환해주는 라이브러리를 사용한다.
73 | 
74 | #### 🙏 Reference
75 | 
76 | - [누구든지 하는 리액트: 9편 불변성을 지키는 이유와 업데이트 최적화](https://velopert.com/3640)
77 | - [리액트의 불변성과 Immutable.js 사용하기 - 1](https://byseop.github.io/2018/06/19/react-immutablejs01.html)
78 | - [React state가 불변이어야 하는 이유](https://medium.com/@ljs0705/react-state%EA%B0%80-%EB%B6%88%EB%B3%80%EC%9D%B4%EC%96%B4%EC%95%BC-%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0-ec2bf09c1021)
79 | 


--------------------------------------------------------------------------------
/Rules/Commit.md:
--------------------------------------------------------------------------------
 1 | # Commit Rules
 2 | 
 3 | ## Commit Type
 4 | 
 5 | 커밋의 사용되는 타입은 크게 4가지로 구분한다.
 6 | 
 7 | - create: Create docs(새로운 문서 생성)
 8 | - update/{reviewerName}: Update docs(PR상 올라가 있는 문서 수정)
 9 | - hotfix: Update docs without brach(Master 머지 후 발견된 수정 사항)
10 | - maintain: Update README.md(기타 문서 수정)
11 | 
12 | ### Example
13 | 
14 | ```md
15 | // 괄호도 포함하는 메시지
16 | 
17 | [create]: Create Scope.md
18 | 
19 | [update] : Scope 설명 코드 예시 보충(최대한 자세하게)
20 | [update/BKJang]: 서브넷 네트워크와 네트워크 주소 차이 추가(최대한 자세하게)
21 | [update/sNyung]: 네트워크 주소 예시 수정(최대한 자세하게)
22 | 
23 | [hotfix]: 띄어쓰기
24 | [hotfix]: 오탈자 수정
25 | 
26 | [maintain]: Update README.md (Add commit message type)
27 | ```
28 | 
29 | ## 커밋 작성 예시
30 | 
31 | ### github.com에서 새로운 파일 올리기
32 | 
33 | ![레포 화면 버튼](https://user-images.githubusercontent.com/24274424/85224874-5199e680-b408-11ea-9ea5-f573d1fbe979.png)
34 | 
35 | > Create new file => Click
36 | 
37 | ![글작성 페이지](https://user-images.githubusercontent.com/24274424/85224898-71310f00-b408-11ea-9079-31ed804861f6.png)
38 | 
39 | > 자신의 글 작성 및 하단으로 이동
40 | 
41 | ![커밋 메시지 작성](https://user-images.githubusercontent.com/24274424/85224950-9f165380-b408-11ea-9cac-d5a00d61a1ff.png)
42 | 
43 | > 커밋메시지 타입 중 create를 사용하여 작성
44 | 
45 | ### github.com에서 파일 수정하기
46 | 
47 | ![PR 화면](https://user-images.githubusercontent.com/24274424/85225028-38456a00-b409-11ea-9c43-8cf821d15f2d.png)
48 | 
49 | > 자신의 PR로 들어감
50 | 
51 | ![image](https://user-images.githubusercontent.com/24274424/85225044-54490b80-b409-11ea-83e3-4fbe1a8eff7e.png)
52 | 
53 | > Files changed => 우측 vertical dots 클릭 => edit file 클릭
54 | 
55 | ![글 수정 및 하단 메시지](https://user-images.githubusercontent.com/24274424/85225071-865a6d80-b409-11ea-997c-bcfbf311cd6b.png)
56 | 
57 | > 글 수정 및 하단 메시지 이동
58 | 
59 | ![update 메시지 작성](https://user-images.githubusercontent.com/24274424/85225088-9eca8800-b409-11ea-870c-b26a30fe36bf.png)
60 | 
61 | > update 타입을 사용하여 작성 및 commit 클릭
62 | 


--------------------------------------------------------------------------------
/Rules/Markdown.md:
--------------------------------------------------------------------------------
  1 | # Mardown_Rule
  2 | 
  3 | ## 대제목
  4 | 
  5 | 당연하게 `#` 한개
  6 | 
  7 | ```
  8 | #
  9 | ```
 10 | 
 11 | ## 중제목
 12 | 
 13 | ```
 14 | ##
 15 | ```
 16 | 
 17 | ## 소제목
 18 | 
 19 | ```
 20 | ###
 21 | 
 22 | --- // # 3개는 라인이 생기지 않으므로 넣어줌
 23 | ```
 24 | 
 25 | ## 리스트
 26 | 
 27 | ```
 28 | 1.
 29 | 2.
 30 | 3.
 31 | ```
 32 | 
 33 | ## 점 리스트
 34 | 
 35 | ```
 36 | -
 37 | ```
 38 | 
 39 | ## 소스
 40 | 
 41 | ```
 42 | `내용` //단어나 한줄짜리
 43 | 
 44 | //Multi line
 45 | ```js
 46 | ```// javascript => 축약형으로
 47 | 
 48 | ```
 49 | 
 50 | ## 사진첨부
 51 | 
 52 | Caption 내용은 파일명_Number로 진행
 53 | 
 54 | ```
 55 | ![파일명_number]()
 56 | ```
 57 | 
 58 | ## 링크
 59 | 
 60 | ```
 61 | []()
 62 | ```
 63 | 
 64 | ## 참조
 65 | 
 66 | ```
 67 | >
 68 | >
 69 | ```
 70 | 
 71 | ## 라인바꾸기
 72 | 
 73 | ```
 74 | <br/>
 75 | ```
 76 | 
 77 | ## 제목간 간격
 78 | 
 79 | ```
 80 | 중제목 
 81 | <br/>
 82 | 중제목
 83 | ```
 84 | 
 85 | ```
 86 | 중제목 //없음
 87 | 소제목
 88 | ```
 89 | 
 90 | ```
 91 | 소제목
 92 | 소제목
 93 | ```
 94 | 
 95 | ## 참조 
 96 | 
 97 | 라인을 넣는 것에 대해서는 지금은 넣는 것으로 진행
 98 | 
 99 | ```
100 | ---
101 | 
102 | #### Reference
103 | ```
104 | 


--------------------------------------------------------------------------------
/Security/HTTPS와 SSL.md:
--------------------------------------------------------------------------------
 1 | # HTTPS와 SSL
 2 | 
 3 | <br/>
 4 | 
 5 | ## HTTP(Hypertext Transfer Protocol)
 6 | 
 7 | HTTP 프로토콜은 Hypertext인 HTML을 전송하기 위한 통신 규약을 의미한다.<br/>교환 방식은 복잡한 바이너리 데이터가 아닌 단순 텍스트를 통해 이뤄진다. 여기서 HTTP프로토콜의 문제가 여실히 드러난다.
 8 | 
 9 | 만약 **서버와 클라이언트간의 데이터를 누군가가 중간에서 가로챘다**고 해보자. 그 데이터를 가로채 변조한다거나 악의적인 감청이 일어난다면 데이터는 **단순 텍스트**이기 때문에 문제가 생길 것이다.<br/>예를 들어, **로그인을 위해서 서버로 비밀번호를 전송**할 때 악의적인 감청이나 데이터의 변조등이 일어날 수 있다는 것이다.
10 | 
11 | 이를 보완한 것이 **HTTPS**고 이를 이해하기 위해선 약간의 암호화 기법 지식이 필요하다.
12 | 
13 | <br/>
14 | 
15 | ## 암호화 기법
16 | 
17 | HTTPS를 설명하기 위해서 알아야 할 암호화 기법에는 **대칭키 암호화 기법**과 **비대칭 키 암호화 기법**이 있다.
18 | 
19 | ### 대칭키 암호화 기법
20 | 
21 | ---
22 | 
23 | 대칭키 암호화 기법은 하나의 키를 가지고 암호화와 복호화가 가능한 것이다. 간단하다.
24 | 
25 | 클라이언트와 서버가 암호화와 복호화 하는 방법을 모두 알고 있다면 이를 대칭키 암호화 기법이라고 보면 된다. 대칭키 암호화 기법은 **암호를 주고 받는 사람들만 키 값을 알고 있다면 안전**하다. 하지만 **문제는 대칭키를 서로 공유하기 힘들다.**
26 | 
27 | 공유를 위해 만약 최초에 클라이언트에서 서버에 데이터를 전송할 때 대칭키를 같이 전송하는 과정에서 대칭키가 해커에게 탈취된다면 암호화 방식 전체를 바꿔야할 것이다.
28 | 
29 | ### 비대칭키 암호화 기법(공개키 암호화)
30 | 
31 | ---
32 | 
33 | 비대칭키 암호화 기법은 암호화와 복호화를 하기 위한 키가 다르다는 것이다. 즉 암호화를 하는 방법과 복호화를 하는 방법이 다르기 때문에 중간에 암호화된 데이터가 탈취된다고 해도 복호화를 할 방법이 없다. 
34 | 
35 | <br/>
36 | 
37 | ![https_asymmetric_key](/assets/images/https_asymmetric_key.png)
38 | 
39 | <br/>
40 | 
41 | 하지만 여기서 생각해봐야 할 것이 있는데 **'서버로 전송된 데이터가 클라이언트에서 전송한 것인지, 안전한 데이터라고 확신할 수 있을까?'** 라는 것이다.
42 | 
43 | <br/>
44 | 
45 | ## HTTPS
46 | 
47 | 이를 위해 우리는 **SSL 인증서**를 사용한다. 서버로 전송된 데이터가 안전한 데이터라는 것을 SSL 인증서를 통해 확인하는 것이다. 그리고 이 인증서를 발급해주는 민간 기관을 **CA**라고 하고 이 **CA 리스트를 브라우저는 내부적으로 가지고 있다.**<br/>즉, 비대칭키 암호화 기법을 이용해 암호화된 데이터를 서버로 전송하는 과정에서 SSL 인증을 받은 데이터만 서버에서는 신뢰하는 것이다.
48 | 
49 | 하지만 이 방식은 느릴 수 있기 때문에 대칭키 암호화와 비대칭키 암호화를 같이 사용하기도 한다.
50 | 
51 | <br/>
52 | 
53 | ---
54 | 
55 | #### Reference
56 | 
57 | * [비둘기로 설명하는 HTTPS(HTTPS explained with carrier pigeons)](https://www.vobour.com/%EB%B9%84%EB%91%98%EA%B8%B0%EB%A1%9C-%EC%84%A4%EB%AA%85%ED%95%98%EB%8A%94-https-https-explained-with-car)
58 | * [무하프로젝트 - HTTP, HTTPS 프로토콜이란? ](http://mohwaproject.tistory.com/entry/HTTPS%EB%9E%80)
59 | * [HTTPS와 SSL 인증서](https://opentutorials.org/course/228/4894)


--------------------------------------------------------------------------------
/Security/리만가설과 소수정리.md:
--------------------------------------------------------------------------------
 1 | # 리만가설과 소수정리, RSA
 2 | 
 3 | 이 세가지는 서로 연관이 있다.
 4 | 
 5 | 리만가설 => 소수정리 => 암호학과 연결된다. 일단 리만가설부터 출발한다.
 6 | 
 7 | ## 리만가설
 8 | 
 9 | 주어진 수보다 작은 소수의 개수에 관하여... 라는 논문에서 제타함수의 성질들을 열거한 것이 리만가설이다.
10 | 
11 | 여기서 소수란 2, 3, 5, 7, 9, 11, 13 등과 같은 수를 말한다.
12 | 
13 | - 관련 수식은 아래와 같다.
14 | 
15 |   ![](https://wikimedia.org/api/rest_v1/media/math/render/svg/e9bd691fccd9541432c60dc5ad456a236fcd395b)
16 | 
17 |   이게 주어진 수(s)보다 작은 소수의 개수를 구하는 방식이다. 이 해를 구하고자 고민하다가 발견한 것이 주어진 수가 -2n의 형식이면(이때 n은 자연수) 항상 0이된다라는 것을 발견했다.
18 | 
19 |   ![](https://wikimedia.org/api/rest_v1/media/math/render/svg/d1fde30fa0ef08e41740321cb277b57f98588d03)
20 | 
21 | - 이 때 수학적으로 -2n의 구조를 자명한 근 이라고 한다. 자명한 근은 확실한 해를 이야기한다. 그렇다면 자명하지 않은 근은 이 반대인 여집합을 말한다.
22 | - 리만에 따르면 자명한 근은 -2n의 구조를 가지며 자명하지 않은 근은 4개를 찾았다. 그런데 모두 a+bi의 복소수 형태를 가지고 있음을 확인했다. 더 나아가 1/2 + 000i(000은 자릿수)의 형태까지 일치함을 확인했다.
23 | - 이 후 다른 더 많은 해를 찾지 못하다가 튜링이 튜링머신을 만들어 자명하지 않은 근을 1104개의 더 찾았으며 모두 이 형식과 같았다.(그래프의 직선상에 위치)
24 | 
25 | ## 소수정리
26 | 
27 | 어떤 양수 이하의 소수가 몇개인가? 라는 질문이다.
28 | 
29 | - 소수정리의 수식은 아래와 같다.
30 | 
31 |   ![](https://wikimedia.org/api/rest_v1/media/math/render/svg/8e4100bd4f7c4e6054eca3fbbfd6a90d3a37c6ec)
32 | 
33 |   이게 x / logx 정도 된다고 한다. 이 소수정리를 증명하는데 리만가설의 제타함수가 사용된다. 그래서 리만가설과 소수정리가 연결된다.
34 | 
35 | - 소수정리를 증명하려면 제타함수의 실수부가 필요하다. 즉 1/2 + 000i 부분의 1/2부분이 필요하다.
36 | 
37 | - 제타함수에서 실수부가 1보다 작다 라는 것만 증명하면 소수정리는 증명된다고 한다.
38 | 
39 | ## 암호학
40 | 
41 | - 이제 암호학과 소수정리를 연결시켜보자.
42 | 
43 | - RSA 암호방식은 소수 x 소수 => 큰 숫자를 만들어 내는 방식이다.
44 | 
45 |   `K1 * K2 = X` 라고 하자. 이 때 K1과 K2는 소수다.
46 | 
47 |   X가 엄청나게 큰 수라면 X만 가지고 K1과 K2를 찾아내기는 쉽지않다.
48 | 
49 |   이게 RSA 암호의 기본 틀이다.
50 | 
51 | - **소수는 규칙이 없다.** 가 현재의 믿음이다.
52 | 
53 |   암호화 후 X만 주고 소인수 분해하여 K1과 K2를 찾아내야지 복호화가 가능하다. 그런데 사실상 K1과 K2를 찾아내는 일은 너무 많은 연산이 필요하다.
54 | 
55 | 이에 만일 리만가설이 증명되어 소수의 규칙을 찾아내는 방식이 나온다면, 현재의 RSA 암호체계가 위협을 받을 수도 있다는 문제가 발생할 수 도 있다. 그래서 현제 리만가설을 풀어내려는 수학 과학계의 움직이미 암호학에 영향을 미칠 수 있어 이슈가 되고 있다.
56 | 


--------------------------------------------------------------------------------
/assets/IndexDB/TodoList/index.html:
--------------------------------------------------------------------------------
 1 | <!DOCTYPE html>
 2 | <html lang="en">
 3 | 
 4 | <head>
 5 |   <meta charset="UTF-8">
 6 |   <meta name="viewport" content="width=device-width, initial-scale=1.0">
 7 |   <meta http-equiv="X-UA-Compatible" content="ie=edge">
 8 |   <title>Document</title>
 9 |   <link href="https://fonts.googleapis.com/css?family=Nanum+Gothic|Noto+Sans+KR&display=swap" rel="stylesheet">
10 |   <link rel="stylesheet" href="todoStyle.css">
11 | </head>
12 | 
13 | <body>
14 |   <div style="margin:auto; width : 80%">
15 |     <h1 id="title">TODO List(IndexedDB)</h1>
16 |     <div class="newTodoContainer defaultContainer">
17 |       <span class="todoSubTitle left">TODO:</span>
18 |       <input type="text" id="newTodoInput" placeholder="새로운 할 일을 적어주세요" autofocus/>
19 |       <button type="button" id="newTodoBtn" class="defaultBtn right">+New</button>
20 |     </div>
21 |     <div id="newTodoList" class="defaultContainer"></div>
22 |     <div class="doneTodoContainer defaultContainer">
23 |       <span class="todoSubTitle left">TODO</span>
24 |       <span class="todoSubTitle bigTitle">Done</span>
25 |       <button type="button" id="removeButton" class="defaultBtn right">Clear</button>
26 |     </div>
27 |     <div id="doneTodoList" class="defaultContainer"></div>
28 |   </div>
29 |   <div class="commonBtnContainer">
30 |     <button type="button" id="buttonAllClear">All Clear</button>
31 |     <button type="button" id="buttonSave">Save</button>
32 |   </div>
33 | </body>
34 | <script type="text/javascript" src="./js/indexDB.js"></script>
35 | <script type="text/javascript" src="./js/todo.js"></script>
36 | 
37 | </html>


--------------------------------------------------------------------------------
/assets/IndexDB/TodoList/js/indexDB.js:
--------------------------------------------------------------------------------
  1 | 
  2 | (function () {
  3 |   console.log('link indexDB file')
  4 |   let idbSupported = false
  5 | 
  6 |   if ("indexedDB" in window) {
  7 |     idbSupported = true;
  8 |   }
  9 | 
 10 |   if (idbSupported) {
 11 |     // indexedDB 열기
 12 |     const openRequest = indexedDB.open("TodoListDB", 1);
 13 | 
 14 |     openRequest.onupgradeneeded = function (e) {
 15 |       console.log("indexedDB onupgradeneeded");
 16 |       const thisDB = e.target.result;
 17 | 
 18 |       // firstOS이라는 저장소가 없으면
 19 |       if (!thisDB.objectStoreNames.contains("TodoListTable")) {
 20 |         // 저장소를 만들어줌
 21 |         thisDB.createObjectStore("TodoListTable", { autoIncrement: true });
 22 |       }
 23 |     }
 24 | 
 25 |     openRequest.onsuccess = function (e) {
 26 |       console.log("indexedDB open Success!");
 27 | 
 28 |       db = e.target.result;
 29 |       const transaction = db.transaction(["TodoListTable"],"readonly");
 30 |       const store = transaction.objectStore("TodoListTable");
 31 | 
 32 |       //기존의 데이터를 불러오기
 33 |       store.getAll().onsuccess = function(e) {
 34 |         const result = e.target.result;
 35 | 
 36 |         for (let index = 0; index < result.length; index++) {
 37 |           const element = result[index];
 38 |           TODO_LIST[element.key] = element
 39 |           if(element.done){
 40 |             document.getElementById(DOINGDONE_ARR[1]).appendChild(createTodoLine(element.value, element.key, element.done));
 41 |           }else{
 42 |             document.getElementById(DOINGDONE_ARR[0]).appendChild(createTodoLine(element.value, element.key, element.done));
 43 |           }
 44 |         }
 45 |       }
 46 |       
 47 |       // 이벤트 등록
 48 |       document.querySelector("#buttonSave").addEventListener("click", addToDoList, false);
 49 |       document.querySelector("#buttonAllClear").addEventListener("click", clearToDoList, false);
 50 |     }
 51 | 
 52 |     openRequest.onerror = function (e) {
 53 |       console.log("Error", e);
 54 |     }
 55 |   }
 56 | 
 57 |   function addToDoPromise(todo) {
 58 |     const promise = new Promise(function(resolve, reject){
 59 |       const transaction = db.transaction(["TodoListTable"], "readwrite");
 60 |       const store = transaction.objectStore("TodoListTable");
 61 |       let request
 62 | 
 63 |       console.log('store', store) 
 64 |       request = store.add(todo);
 65 |   
 66 |       request.onerror = function (e) {
 67 |         console.warn("Error", e.target.error.name);
 68 |         reject()
 69 |       }
 70 |   
 71 |       request.onsuccess = function (e) {
 72 |         console.log("Woot! Did it", todo);
 73 |         resolve()
 74 |       }
 75 |     })
 76 |     return promise
 77 |   }
 78 | 
 79 |   function addToDoList(e) {
 80 |     let resolve = Promise.resolve();
 81 |     const values = Object.values(TODO_LIST);
 82 | 
 83 |     if(values.length === 0){
 84 |       alert("저장할 내역이 없습니다.");
 85 |       return;
 86 |     }
 87 | 
 88 |     const transaction = db.transaction(["TodoListTable"], "readwrite");
 89 |     const store = transaction.objectStore("TodoListTable");
 90 |     store.clear();
 91 | 
 92 |     for (let index = 0; index < values.length; index++) {
 93 |       const element = values[index];
 94 |       resolve = resolve.then(addToDoPromise(element))
 95 |     }
 96 | 
 97 |     resolve.then(() => {
 98 |       alert("저장완료")
 99 |     })
100 |   }
101 | 
102 |   function clearToDoList(e) {
103 |     const transaction = db.transaction(["TodoListTable"], "readwrite");
104 |     const store = transaction.objectStore("TodoListTable");
105 |     store.clear();
106 |   }
107 | })()


--------------------------------------------------------------------------------
/assets/IndexDB/TodoList/js/todo.js:
--------------------------------------------------------------------------------
 1 | const TODO_LIST = {};
 2 | const DOINGDONE_ARR = ["newTodoList", "doneTodoList"];
 3 | 
 4 | const createTodoLine = (inputValue, key, done = 'false') => {
 5 |   const newTodoContainer = document.createElement("div");
 6 |   const newCheckbox = document.createElement("input");
 7 |   const newSpan = document.createElement("span");
 8 | 
 9 |   newTodoContainer.dataset.key = key
10 |   newTodoContainer.className = "todoContainer"
11 | 
12 |   newSpan.textContent = inputValue
13 |   newSpan.className = "newTodoText"
14 | 
15 |   newCheckbox.setAttribute("type", "checkbox");
16 |   newCheckbox.checked = done
17 |   newCheckbox.addEventListener("click", moveTodo);
18 | 
19 |   newTodoContainer.appendChild(newCheckbox);
20 |   newTodoContainer.appendChild(newSpan);
21 | 
22 |   return newTodoContainer;
23 | }
24 | 
25 | const moveTodo = (e) => {
26 |   const checkbox = e.target;
27 |   const parentId = checkbox.parentNode.parentNode.getAttribute("id");
28 |   const moveIndex = Math.abs(DOINGDONE_ARR.length - DOINGDONE_ARR.indexOf(parentId) - 1)
29 | 
30 |   TODO_LIST[checkbox.parentNode.dataset.key].done = !TODO_LIST[checkbox.parentNode.dataset.key].done
31 | 
32 |   document.getElementById(DOINGDONE_ARR[moveIndex]).appendChild(checkbox.parentNode);
33 | }
34 | 
35 | (function () {
36 |   console.log('Run Todo JS file')
37 | 
38 |   // keydown과 관련된 handler추가
39 |   const keydownHandler = (e) => {
40 |     switch (e.keyCode) {
41 |       case 13:
42 |         generateTodo(e.target.value);
43 |         break;
44 | 
45 |       default:
46 |         break;
47 |     }
48 |   }
49 | 
50 |   // Create Todo
51 |   const generateTodo = function (inputValue) {
52 |     if (inputValue === '') {
53 |       alert('내용을 입력해주세요')
54 |       return
55 |     }
56 |     const todo = {
57 |       key: '_' + Math.random().toString(36).substr(2, 9),
58 |       value: inputValue,
59 |       done: false,
60 |       created: new Date()
61 |     }
62 | 
63 |     // Append New Todo
64 |     document.getElementById(DOINGDONE_ARR[0]).appendChild(createTodoLine(inputValue, todo.key, false));
65 |     TODO_LIST[todo.key] = todo
66 |     // Reset InputBox
67 |     document.getElementById("newTodoInput").value = "";
68 |   }
69 | 
70 |   const removeAllTodo = function () {
71 |     removeNewTodo();
72 |     removeDoneTodo();
73 |   }
74 | 
75 |   const removeNewTodo = function () {
76 |     const newTodoContainer = document.getElementById(DOINGDONE_ARR[0]);
77 | 
78 |     while (newTodoContainer.firstChild) {
79 |       delete TODO_LIST[newTodoContainer.firstChild.dataset.key]
80 |       newTodoContainer.removeChild(newTodoContainer.firstChild);
81 |     }
82 |   }
83 | 
84 |   const removeDoneTodo = function () {
85 |     const doneTodoContainer = document.getElementById(DOINGDONE_ARR[1]);
86 | 
87 |     while (doneTodoContainer.firstChild) {
88 |       delete TODO_LIST[doneTodoContainer.firstChild.dataset.key]
89 |       doneTodoContainer.removeChild(doneTodoContainer.firstChild);
90 |     }
91 |   }
92 | 
93 |   document.getElementById("newTodoInput").addEventListener("keydown", keydownHandler, false)
94 |   document.getElementById("newTodoBtn").addEventListener("click", () => generateTodo(document.getElementById("newTodoInput").value), false)
95 |   document.getElementById("removeButton").addEventListener("click", removeDoneTodo, false)
96 |   document.getElementById("buttonAllClear").addEventListener("click", removeAllTodo, false)
97 | })()
98 | 
99 | 


--------------------------------------------------------------------------------
/assets/IndexDB/TodoList/todoStyle.css:
--------------------------------------------------------------------------------
  1 | html body{
  2 |   font-family: 'Noto Sans KR', sans-serif;
  3 |   font-family: 'Nanum Gothic', sans-serif;
  4 |   font-size: 16px;
  5 | }
  6 | 
  7 | #title{
  8 |   text-align: center;
  9 | }
 10 | 
 11 | .defaultContainer{
 12 |   margin : 10px;
 13 |   padding : 10px;
 14 |   border: 2px solid black;
 15 | 
 16 |   min-height: 20px;
 17 | }
 18 | 
 19 | .newTodoContainer, .doneTodoContainer{
 20 |   text-align: center;
 21 | }
 22 | 
 23 | .todoSubTitle{
 24 |   font-size: 18px;
 25 |   font-weight: bold;
 26 | }
 27 | 
 28 | .commonBtnContainer{
 29 |   text-align: center;
 30 |   padding : 10px;
 31 | }
 32 | 
 33 | .defaultBtn{
 34 |   display: inline-block;
 35 |   position: static;
 36 | 
 37 |   color: black;
 38 |   background-color: white;
 39 | 
 40 |   border: 1px solid black;
 41 |   border-radius: 10px;
 42 | 
 43 |   width: 70px;
 44 |   height: 25px;
 45 | }
 46 | 
 47 | .defaultBtn:hover{
 48 |   color: white;
 49 |   background-color: darkgrey;
 50 |   border: 1px solid darkgrey;
 51 |   box-shadow: 0px 0px 5px 2px lightgrey;
 52 | }
 53 | 
 54 | .defaultBtn:active{
 55 |   color: white;
 56 |   background-color: darkkhaki;
 57 |   border: 1px solid darkkhaki;
 58 |   box-shadow: 0px 0px 5px 2px lightgrey;
 59 | }
 60 | 
 61 | .todoContainer{
 62 |   margin: 0px 5px;
 63 |   padding: 10px 0px;
 64 | 
 65 |   font-size: 16px;
 66 | 
 67 |   border-bottom: 0.5px solid lightgrey;
 68 | 
 69 |   width: 100%;
 70 | }
 71 | 
 72 | .newTodoText{
 73 |   margin: 5px;
 74 |   font-size: 16px;
 75 | }
 76 | 
 77 | #newTodoInput{
 78 |   padding : 3px;
 79 |   font-size: 14px;
 80 |   width: 65%
 81 | }
 82 | 
 83 | #buttonSave, #buttonAllClear{
 84 |   display: inline-block;
 85 |   position: static;
 86 | 
 87 |   margin: auto;
 88 |   margin-top: 5px;
 89 |   margin-bottom: 5px;
 90 | 
 91 |   color: black;
 92 |   background-color: white;
 93 | 
 94 |   border: 1px solid black;
 95 |   font-size: 18px;
 96 |   font-weight: bold;
 97 | 
 98 |   width: 200px;
 99 |   height: 40px;
100 | }
101 | 
102 | #buttonSave:hover{
103 |   color: white;
104 |   background-color: darkgrey;
105 |   border: 0px
106 | }
107 | 
108 | #buttonAllClear:hover{
109 |   color: white;
110 |   background-color: darkgreen;
111 |   border: 0px
112 | }
113 | 
114 | #buttonSave:active, #buttonAllClear:active{
115 |   color: black;
116 |   background-color: white;
117 |   border: 0px
118 | }
119 | 
120 | ::-webkit-input-placeholder { /* Chrome/Opera/Safari */
121 |   color: pink;
122 |   font-size: 14px;
123 | }
124 | 
125 | .left {
126 |   float:left;
127 | }
128 | 
129 | .right {
130 |   float:right;
131 | }
132 | 
133 | .bigTitle {
134 |   font-size: 22px;
135 | }
136 | 


--------------------------------------------------------------------------------
/assets/TEST/img_css_image_sprites.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/TEST/img_css_image_sprites.png


--------------------------------------------------------------------------------
/assets/TEST/window.history.demo.html:
--------------------------------------------------------------------------------
 1 | <!DOCTYPE html>
 2 | <html lang="ko">
 3 | <head>
 4 |   <meta charset="UTF-8">
 5 |   <meta name="viewport" content="width=device-width, initial-scale=1.0">
 6 |   <meta http-equiv="X-UA-Compatible" content="ie=edge">
 7 |   <title>Document</title>
 8 | </head>
 9 | <body>
10 |   <div id='app'/>
11 | </body>
12 | <script>
13 | 
14 | window.onpopstate = function(event) {
15 |   console.log("location: " + document.location + ", state: " + JSON.stringify(event.state));
16 | 
17 |   
18 |   const divElement = document.getElementById('app')
19 | 
20 |   // Remove all child Element
21 |   // more faster than innerHTML = '';
22 |   while (divElement.firstChild) {
23 |     divElement.removeChild(divElement.firstChild);
24 |   }
25 | 
26 |   const curState = event.state
27 |   if(curState.length === 0) return
28 | 
29 |   const todoList = curState.todoList
30 |   
31 |   for (let index = 0; index < todoList.length; index++) {
32 |     const element = todoList[index];
33 |     divElement.insertAdjacentHTML('beforeend', `<div id="two">${element}</div>`); 
34 |   }
35 | };
36 | 
37 | const history = window.history
38 | const page1State = {
39 |   todoList : ['aaa', 'aaa', 'aaa', 'aaa'],
40 | };
41 | const page2State = {
42 |   todoList : ['bbb', 'bbb', 'bbb', 'bbb'],
43 | };
44 | 
45 | history.pushState(page1State, "page1", "page1.html");
46 | history.pushState(page2State, "page2", "page2.html");
47 | </script>
48 | </html>


--------------------------------------------------------------------------------
/assets/gif/MobileCSS.gif:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/gif/MobileCSS.gif


--------------------------------------------------------------------------------
/assets/gif/MobileDock.gif:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/gif/MobileDock.gif


--------------------------------------------------------------------------------
/assets/gif/MobileLayout.gif:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/gif/MobileLayout.gif


--------------------------------------------------------------------------------
/assets/images/CallByValue.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/CallByValue.png


--------------------------------------------------------------------------------
/assets/images/Collection_Hierarchies.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/Collection_Hierarchies.png


--------------------------------------------------------------------------------
/assets/images/EventLoop.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/EventLoop.png


--------------------------------------------------------------------------------
/assets/images/Functional_Programming_Main.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/Functional_Programming_Main.png


--------------------------------------------------------------------------------
/assets/images/Gecko.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/Gecko.jpg


--------------------------------------------------------------------------------
/assets/images/Graph-그래프.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/Graph-그래프.png


--------------------------------------------------------------------------------
/assets/images/Graph-리스트_무향.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/Graph-리스트_무향.png


--------------------------------------------------------------------------------
/assets/images/Graph-리스트_유향.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/Graph-리스트_유향.png


--------------------------------------------------------------------------------
/assets/images/Graph-보행.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/Graph-보행.png


--------------------------------------------------------------------------------
/assets/images/Graph-종류.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/Graph-종류.png


--------------------------------------------------------------------------------
/assets/images/Graph-쾨니헤스베르크_다리.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/Graph-쾨니헤스베르크_다리.png


--------------------------------------------------------------------------------
/assets/images/Graph-크기.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/Graph-크기.png


--------------------------------------------------------------------------------
/assets/images/Graph-행렬.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/Graph-행렬.png


--------------------------------------------------------------------------------
/assets/images/HTML-Templating1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/HTML-Templating1.png


--------------------------------------------------------------------------------
/assets/images/HTML-Templating2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/HTML-Templating2.png


--------------------------------------------------------------------------------
/assets/images/HTML-Templating3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/HTML-Templating3.png


--------------------------------------------------------------------------------
/assets/images/HTMLCollection.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/HTMLCollection.png


--------------------------------------------------------------------------------
/assets/images/HashTable.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/HashTable.png


--------------------------------------------------------------------------------
/assets/images/LongPolling.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/LongPolling.png


--------------------------------------------------------------------------------
/assets/images/Parent_Child_workflow.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/Parent_Child_workflow.png


--------------------------------------------------------------------------------
/assets/images/SQL_Injection_1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/SQL_Injection_1.png


--------------------------------------------------------------------------------
/assets/images/SQL_Injection_2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/SQL_Injection_2.png


--------------------------------------------------------------------------------
/assets/images/ScopeChain.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/ScopeChain.png


--------------------------------------------------------------------------------
/assets/images/ServletClass.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/ServletClass.png


--------------------------------------------------------------------------------
/assets/images/Sync&Async_Multi&Single_Thread_1.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/Sync&Async_Multi&Single_Thread_1.jpg


--------------------------------------------------------------------------------
/assets/images/Vue-lifecycle.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/Vue-lifecycle.png


--------------------------------------------------------------------------------
/assets/images/Webkit.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/Webkit.png


--------------------------------------------------------------------------------
/assets/images/ajax.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/ajax.png


--------------------------------------------------------------------------------
/assets/images/array_list.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/array_list.png


--------------------------------------------------------------------------------
/assets/images/bucket-sort.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/bucket-sort.png


--------------------------------------------------------------------------------
/assets/images/call-by-sharing01.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/call-by-sharing01.png


--------------------------------------------------------------------------------
/assets/images/coalescing.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/coalescing.png


--------------------------------------------------------------------------------
/assets/images/compaction.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/compaction.png


--------------------------------------------------------------------------------
/assets/images/compilerDesign.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/compilerDesign.jpg


--------------------------------------------------------------------------------
/assets/images/copy-object01.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/copy-object01.png


--------------------------------------------------------------------------------
/assets/images/event_delegation.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/event_delegation.png


--------------------------------------------------------------------------------
/assets/images/event_loop.jpeg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/event_loop.jpeg


--------------------------------------------------------------------------------
/assets/images/event_loop_gif.gif:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/event_loop_gif.gif


--------------------------------------------------------------------------------
/assets/images/flux_architecture.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/flux_architecture.png


--------------------------------------------------------------------------------
/assets/images/get&post.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/get&post.png


--------------------------------------------------------------------------------
/assets/images/gitBy_.git_gitlifecycle.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/gitBy_.git_gitlifecycle.png


--------------------------------------------------------------------------------
/assets/images/gitBy_.git_gitobjects.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/gitBy_.git_gitobjects.png


--------------------------------------------------------------------------------
/assets/images/https_asymmetric_key.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/https_asymmetric_key.png


--------------------------------------------------------------------------------
/assets/images/hystrix.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/hystrix.png


--------------------------------------------------------------------------------
/assets/images/insertAdjacentHTML_1.PNG:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/insertAdjacentHTML_1.PNG


--------------------------------------------------------------------------------
/assets/images/insertAdjacentHTML_2.PNG:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/insertAdjacentHTML_2.PNG


--------------------------------------------------------------------------------
/assets/images/insertAdjacentHTML_3.PNG:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/insertAdjacentHTML_3.PNG


--------------------------------------------------------------------------------
/assets/images/java_Runtime_Data_Areas.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/java_Runtime_Data_Areas.jpg


--------------------------------------------------------------------------------
/assets/images/java_gc_heap.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/java_gc_heap.png


--------------------------------------------------------------------------------
/assets/images/java_gc_object.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/java_gc_object.png


--------------------------------------------------------------------------------
/assets/images/java_runtime_data_area.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/java_runtime_data_area.png


--------------------------------------------------------------------------------
/assets/images/javascript의_동작원리-실행컨텍스트(ExecutionContexts)-1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/javascript의_동작원리-실행컨텍스트(ExecutionContexts)-1.png


--------------------------------------------------------------------------------
/assets/images/javascript의_동작원리-실행컨텍스트(ExecutionContexts)-2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/javascript의_동작원리-실행컨텍스트(ExecutionContexts)-2.png


--------------------------------------------------------------------------------
/assets/images/linked_list.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/linked_list.png


--------------------------------------------------------------------------------
/assets/images/memoryHier.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/memoryHier.png


--------------------------------------------------------------------------------
/assets/images/memorymodel.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/memorymodel.png


--------------------------------------------------------------------------------
/assets/images/non-blocking.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/non-blocking.png


--------------------------------------------------------------------------------
/assets/images/non-linear-search-bfs.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/non-linear-search-bfs.png


--------------------------------------------------------------------------------
/assets/images/non-linear-search-dfs.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/non-linear-search-dfs.png


--------------------------------------------------------------------------------
/assets/images/non-linear-search.gif:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/non-linear-search.gif


--------------------------------------------------------------------------------
/assets/images/page_pageframe.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/page_pageframe.png


--------------------------------------------------------------------------------
/assets/images/polling.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/polling.png


--------------------------------------------------------------------------------
/assets/images/preflight-process.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/preflight-process.png


--------------------------------------------------------------------------------
/assets/images/primitiveCasting.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/primitiveCasting.png


--------------------------------------------------------------------------------
/assets/images/prototype1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/prototype1.png


--------------------------------------------------------------------------------
/assets/images/prototype2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/prototype2.png


--------------------------------------------------------------------------------
/assets/images/react_lifecylce.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/react_lifecylce.png


--------------------------------------------------------------------------------
/assets/images/rendering.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/rendering.png


--------------------------------------------------------------------------------
/assets/images/segmentation.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/segmentation.png


--------------------------------------------------------------------------------
/assets/images/server_side.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/server_side.png


--------------------------------------------------------------------------------
/assets/images/servletArchitecture.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/servletArchitecture.png


--------------------------------------------------------------------------------
/assets/images/streaming.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/streaming.png


--------------------------------------------------------------------------------
/assets/images/typescript_access_modifier.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/typescript_access_modifier.png


--------------------------------------------------------------------------------
/assets/images/typescript_type.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/typescript_type.png


--------------------------------------------------------------------------------
/assets/images/was1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/was1.png


--------------------------------------------------------------------------------
/assets/images/was2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/was2.png


--------------------------------------------------------------------------------
/assets/images/was3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/was3.png


--------------------------------------------------------------------------------
/assets/images/was4.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/im-d-team/Dev-Docs/785fb0814164d7d5eb521ec26c4559649f297eaa/assets/images/was4.png


--------------------------------------------------------------------------------