
`position:fixed` 인 nav 바의 3단 햄버거(한자 '석 삼')를 클릭하면 블로그 카테고리 리스트가 뜨되, 스크롤 시 그 아래로 지나가지 않게 하기

## 방법

JS의 ```toggle()```을 사용하면 된다.

## Toggle

![toggle](/images/blog/2203/toggle.png)

MDN 문서를 읽어보면 toggle()은 DOMTokenList(HTML Element의 classList 등)의 메소드다. 
그 리스트에 파라미터(토큰)가 있는지 확인하고, 없으면 추가한 뒤 true를 리턴한다.

예를 들어 ```HTMLElement.classList.toggle('show')``` 을 하면 HTMLElement 의 클래스 목록에 'show'가 있는지를 확인하고, 있으면 true, 없으면 추가하고 true를 리턴한다.

## HTML

```html
<div id="threeBarNav" class="container" hidden onclick="clickNav(this)">
    <div class="bar1"></div>
    <div class="bar2"></div>
    <div class="bar3"></div>
</div>
```

## JS

```js
function clickNav(x) {
    x.classList.toggle("open");
    const nav = x.parentNode
    nav.classList.toggle("open")
}
```

그래서 햄버거 바를 만들때도 js onclick에 toggle()를 넣어서 `classList.toggle` 하게 하면 된다.  
그리고 open이면 그에 맞는 css를 적용해주면 끝이다!


JS toggle로 고정된 네비게이션 햄버거 바 만들기


블로그의 디자인을 대폭 수정했다. 수정하기 전엔 이렇게 생겼었다.

![blog 수정전 ](/images/blog/2202/toomanywords.gif)

디자인에 뭔가 부족한 게 있는 것같고, 애매해서 생각해보니 블로그 대문(첫 화면)에 글씨가 너무 많았다.   
문제는 최근 작성한 글 목록 부분이었다.  

![recent posts](/images/blog/2202/rp.png)

어떻게 수정하지 고민을 많이 했고 awwward 수상작들과 여러 사이트들을 보면서 영감을 (ㅋㅋㅋ) 느끼려고 애썼다. 

그러고보니 내가 원하는 페이지는 노션으로 만든 듯한 깔끔한 페이지였다. 그래서 뚝딱뚝딱 수정을 해보았고.. 바뀐 모습은 이렇다.

![메인 윗부분](/images/blog/2202/redes5.PNG)

## 디자인하며 중점적으로 생각한 부분

### 데스크탑과 모바일로 접속했을 때 느낌이 너무 다르지 않게 하기

나는 웹에서 좌우 여백을 많이 주는 페이지를 좋아한다. 그렇게 하려면 웹-앱의 생김새를 비슷하게 해야했다. 둘의 간격이 커지면 미디어쿼리로 처리하는 부분, 신경써야하는 부분이 늘어나 개발할 때 힘들다.

이러려면 웹에서 봤을 때도 좌우 패딩을 안 주고, 세로로 봤을 때 좌우 여백이 없이 일자로 깔끔하게 내려가는 것이 중요했다.
또 모바일에서 볼 때 폰트가 너무 작으면 이 느낌이 덜 했다. 그래서 max-width로 데스크탑에서 봤을 때에도 모바일과 봤을때 차이가 없도록 하고, 앱에서는 거슬릴 지 않는 정도의 좌우 마진만 주었다.

### 간결하고 깔끔하게

그래서 메인 배경 색을 하얀색으로 잡았다. 원래는 메인의 ```Recent Posts``` 섹션에서 카테고리 별 최근글을 보여주었다. 근데 그렇게 하다보니 카테고리명도 나와야하고 또 내가 한동안 쓰지 않은 카테고리의 글이 나오길래 과감하게 카테고리를 지우고 모든 카테고리의 최근글을 표시하도록 했다.

블로그를 직접 디자인해 만들면서 최근 글 영역의 디자인을 가장 많이 고민했다. 카드 형식으로 할지, 글의 도입부를 살짝 보여줄지, 가벼운 요약(description)을 보여줄지 등.. 근데 첫 화면에 글이 너무 많으면 처음 내 블로그에 들어온 사람이 부담을 느낄 것 같아 제목만 띄우기로 했다.

### 테마는 거미 / 남색

사용자가 보게 될 첫 화면에 책 저지대의 구절을 넣고 싶었다. 빼고 기술적인 내용을 적을까 생각도 했지만, '지금까지는' 내가 추구하는 삶을 잘 보여주는 글귀라 남겨두었다.


저는 디자인이 너무너무 어렵습니다

내 블로그 겸 포트폴리오를 직접 디자인하며 주의한 것, 알게된 것


세마포어: 프로그래머 관점에서 프로세스를 잘 동기화하는 방법을 보여주는 추상적 접근법.  
고전적인 프로세스 동기화 관련 문제에 대해 알아본다.

## Concurrency Control (병행 제어)

- 프로세스 동기화와 같은 얘기임. 병행 작업할때 잘 제어 하자^^

## Bounded-Buffer Problem (Producer-consumer Problem)

- Bounded Buffer = 유한하다.

<img width="564" alt="스크린샷 2022-02-25 오후 2 06 16" src="https://user-images.githubusercontent.com/50111853/155657222-846c743e-a75c-4253-bbd9-e1f148998db1.png"/>

- 주황색이 데이터가 들어있는 버퍼들 / 회색이 비어있는 버퍼들. 생산자가 버퍼에 데이터를 집어넣는다.
- producer, consumer 프로세스로 총 2 종류의 프로세스가 있음. 이때 프로듀서 프로세스 여러개, 컨수머 프로세스 여러개 가능
- 생산자: Empty buffer에 데이터를 만들어 집어넣는 역할
- 소비자: Full buffer에 데이터를 꺼내감

### 동기화 관련해 일어날 수 있는 문제

1. 공유버퍼이므로 생산자 둘이 한 버퍼에 데이터를 넣으려고 할 수도 있음
2. 소비자 둘이 동시에 데이터를 꺼내가려할 수도 있음
-> 데이터를 넣고 꺼내기 전에 Lock을 걸음으로써 해결가능

### 이 문제에서 semaphore 용도

1. shared data의 mutual exclusion을 위해 binary semaphore 필요
2. 가용 자원(empty buffer)의 개수를 센다 (counting semaphore)

### Bounded-buffer 코드로 해결하기

![바운디드 버퍼 문제 코드](https://user-images.githubusercontent.com/50111853/155870391-2ba9b914-bc80-4b99-b532-2db360b4b13b.png)

- mutex: 락을 걸기 위한 변수 (세마포어)
- P(mutex), V(mutex)가 락을 걸고 푸는 연산임.

## Readers-Writers Problem

![reader-writer problem](https://user-images.githubusercontent.com/50111853/155870504-e706a0ac-4497-4804-b246-db9e4025e43b.png)

- 공유 데이터인 DB의 데이터를 읽고 쓸 때 문제
- **write는 동시에 하면 안 되지만 read는 동시에 가능**

![읽고 쓸 때 문제 해결](https://user-images.githubusercontent.com/50111853/155870566-2f8f3018-ff33-4ecd-91d1-74527f4a74ff.png)

- reader도 writer처럼 배타적으로 해도 되지만 비효율적임
- Reader에선 readcount++함으로서 읽고 있는 자원의 수를 카운트할 수 있음.
- 다만 readcount도 공유 변수라 이거 값 바꿀 때 락 걸고 변경해야함!!!
- 내가 마지막으로 읽고 나가는 프로세스면(if readcount==0) DB에 걸어둔 락을 풀어야함
- reader가 계속 올 경우 writer starvation 될 수도.

## Dining-Philosophers 문제

<img width="412" alt="식사하는 철학자 문제" src="https://user-images.githubusercontent.com/50111853/155872584-47cf73f4-e7a9-423c-995d-6c34f20c7bc0.png"/>

- 철학자들은 밥을 먹거나 생각하거나 둘 중에 하나를 한다.
- 젓가락이 각각 공유자원이고, initially all values are 1 (하나씩 있다)
- 위 코드는 데드락 가능성이 있다.(=모든 철학자가 동시에 젓가락을 든 경우)

### 위 문제 해결 방안 3가지

1. 4명의 철학자만 테이블에 동시에 앉도록 한다
2. 젓가락을 두개 잡을 수 있을 때에만 젓가락을 집게 한다
3. 비대칭 (짝수-왼쪽 젓가락, 홀수-오른쪽 젓가락부터 잡을 수 있도록 제한)

<img width="570" alt="식사하는 철학자 문제" src="https://user-images.githubusercontent.com/50111853/155874415-c1390407-f806-4d66-8b22-a7c6939c9515.png"/>

#### pickup(int i): 젓가락을 잡는 함수

#### test(): 젓가락 들 수 있는 환경인지 확인하는 함수

- 왼쪽, 오른쪽 철학자가 밥 먹고 있으면 if문 만족하지 않아 락 풀지 못함

## 세마포어의 문제점과 그를 보완해주는 모니터

<img width="705" alt="세마포어의 문제점" src="https://user-images.githubusercontent.com/50111853/155872690-5a04d48a-ea2f-4efa-ae5d-04003b0af62d.png"/>

- 세마포어는 동기화하는 법을 알려주고 프로그래머가 제어할 수 있도록 함.
- 모니터: 프로그래밍 언어 차원에서 공유 자원에 접근하는 일을 모니터가 직접 하게 해 프로그래머의 부담을 줄여줌.
- 세마포어는 정확도를 검증하기 어려움/ 프로그래머의 실수가 영향을 끼칠 수 있다. (= 안정성 낮음)
- monitor: 자바의 인스턴스 각각이 lock을 가진다. 자바 내부적으로 모니터를 가지고 있어 synchronized를 쓰면 각 인스턴스의 모니터를 사용할 수 있다.

<img width="501" alt="모니터" src="https://user-images.githubusercontent.com/50111853/155874579-7c3a92a3-f2ce-4af4-8c28-ef16f9b8d7de.png"/>

- 공유데이터에 접근하려면 내부의 프로시저인 모니터를 통해야만함
- 공유 데이터에 접근하는 프로시저를 함수로 구현해두었음
- 모니터 내부 프로시저는 동시에 여러개가 실행이 불가능하도록 모니터가 막고 있음 => **락을 걸 (P,V연산 할) 필요 없음**
- 모니터 안에선 한 프로세스만 활성화된다. 액티브 프로세스가 1개만 있도록 모니터 자체에서 제어한다!!

<img width="509" alt="condition variable" src="https://user-images.githubusercontent.com/50111853/155874631-c2f1adf3-33ea-41d9-a063-304b4d983c26.png"/>

### condition variable

<img width="500" alt="바운디드 버퍼 문제와 조건 변수" src="https://user-images.githubusercontent.com/50111853/155874643-18666c98-a0e3-481a-a93c-e032686834d6.png"/>

- 특정 조건을 만족하지 않은 프로세스를 잠들게 하는데 그 때 그 조건: 컨디션 var
- 위 bonded buffer 문제를 condition var로 해결하자면 공유버퍼가 모니터 안에 있음
- 그래서 생산자든 소비자든 모니터 안에서 활성화되므로 락 걸 필요 X
- 만약 다른 놈이 있을 경우 **빈 버퍼를 기다리는 큐(생산자) 또는 내용이 들어있는 버퍼를 기다리는 큐(소비자)**에 줄을 서고 producer->produce, consumer-> consume 함수 앞에서 기다리며 잠든다.

x.wait(): 프로세스 재워라
x.signal(): 깨워라

## 느낀 점

지난 차시에 내가 binary semaphore = mutex라고 했었다. 바이너리 세마포는 값이 0과 1 중 하나만 가능하기 때문에 '사용 가능한 자원이 있다 또는 없다'를 나타낸다. 뮤텍스 락과 유사하게 상호 배제의 기능을 가진다. 몇몇 시스템에선 아예 뮤텍스 락 없이 이진 세마포가 대신 상호 배제를 보장한다. 이 둘의 차이는 바로 락을 해제할 수 있는 프로세스이다. 뮤텍스의 경우 락을 건 프로세스 자신만이 락을 해제할 수 있는 반면 이진 세마포어의 경우 다른 프로세스가 락을 해제할 수 있다. 누군가에게 세마포어를 설명할 때, '여러 프로세스가 동시에 한 자원에 접근하는 걸 막고자 락을 걸 때, 프로세스가 사용 가능한 자원의 토탈 개수를 나타내는 변수'라고 설명하면 되는 걸까?!

## 복습 문제

1. bounded-buffer problem에서 소비자 프로세스가 데이터를 꺼내갈 때 데이터를 꺼낼 Full 버퍼에만 락을 건다. (O,X)
정답: X, 공유 버퍼 전체에 락을 건다.

2. dining philosophers 문제에서 데드락이 발생하는 경우는?
정답: 모든 철학자가 동시에 젓가락을 잡으려고 하는 경우

3. monitor에서 프로세스가 wait()할 때, 생산자 프로세스는 (꽉 찬/빈) 버퍼를 기다리는 큐에 줄을 서고 소비자 프로세스는 (꽉 찬/빈) 버퍼를 기다리는 큐에 줄을 선다.
정답: 빈, 꽉 찬


프로세스 동기화 관련 문제를 풀어보자 (Bounded-buffer 등)


## 데이터의 접근

Storage Box: Memory 주소 공간  
Execution Box: CPU 프로세스

![컴퓨터 시스템 내 데이터의 접근](https://user-images.githubusercontent.com/50111853/154946794-c1e3a6c1-358d-4b1b-9432-3283ff4300d1.png)

- `저장소(스토리지) <-> 연산(실행)하는 곳` / 어디서든 컴퓨터 시스템에서 이런 경로를 거침
- 데이터가 왔다갔다하고 **여러 execution box가 한 스토리지를 공유하기도** 함. 이때 동기화는 어떻게?

![race condition](https://user-images.githubusercontent.com/50111853/154947007-68147f7c-589d-48d1-a10e-e50a6e4aa0eb.png)

## race condition

- 달리기 레이스처럼 경쟁상태/ 다른 execution box에서 하나의 데이터를 동시에 접근하는 상황  
- 공유메모리를 사용하는 프로세스들간 / 커널 내부 데이터를 접근하는 루틴들 간 (e.g. 커널모드 수행 중에 인터럽트로 커널모드의 다른 루틴 수행)

### 운영체제에서 레이스 컨디션(동시접근)이 발생하는 순간

1. 커널모드 실행중인데 인터럽트가 발생해서 인터럽트 처리루틴 수행될때

   - 둘 다 커널 코드라 커널 주소 공간을 공유

2. 프로그램이 실행될때 유저모드였다가 커널모드였다가 한다.  

   - 커널모드에 있는 프로그램은 CPU를 빼앗는지 않는다.
   - time quantum system은 real system이 아니라 좀 늦게 뺏어도 상관없음.

### Critical Section (임계 구역)

- **다수의 프로세스가 공유 데이터를 동시에** 사용하기 원하는 경우, 각 프로세스의 code segment에는 공유 데이터에 접근하는 코드인 critical section이 존재.
- 한 프로세스가 이미 **critical section**에 있으면 다른 모든 프로세스는 그 안에 들어갈 수 없음.

### critical section 를 소프트웨어 적에서 해결하기 위한 알고리즘

```c
do {
  entry section
  critical section
  exit section
  remainder section
} while(1);
```

### 위 알고리즘의 충족 조건

1. Mutual exclusion(상호 배제) : 한 놈이 이미 안에 있으면 다른 애들은 못 들어감
2. Progress: 아무도 critical section에 없는데 들어가고자하는 프로세스가 있으면 들어가게 해줘야함
3. Bounded waiting(유한 대기): 프로세스가 들어가려고 요청한 후로 언젠간 들어가야한다.

## 알고리즘 1

![고급언어로 짠 알고리즘](https://user-images.githubusercontent.com/50111853/154952318-6d2ac8c4-9604-4719-8b5d-797cd5dda2d0.png)

- 본인의 차례가 아닌 동안 while 돌다가 상대가 critical section에서 나올 때 (=자기 차례가 되면) turn이 1이 됨
- 이 경우 본인이 크리티컬 섹션에 들어갔다가 나와야 상대 차례고 vice versa
- --> p1은 크리티컬 섹션에 여러번, P1는 한번만 들어가고 싶으면 어떡함?
- -> **progress를 잘 충족하지 못한** 알고리즘임.

## 알고리즘 2

![스크린샷 2022-02-21 오후 9 09 35](https://user-images.githubusercontent.com/50111853/154952631-2ead4d13-0160-45bb-955d-6ac696055f77.png)

- 내가 크리티컬 섹션 들어갈 때 플래그를 1로 바꿈.
- 문제: 둘다 깃발만 들고 끊임없이 양보할 수도 있음.

## 알고리즘 3 (피터슨의 알고리즘)

![스크린샷 2022-02-21 오후 9 12 25](https://user-images.githubusercontent.com/50111853/154953064-5932358f-95d3-4cf6-ac52-ac2fce97a769.png)

- 둘다 들어가고싶을때만 니턴 내턴을 따지고, 한 프로세스만 관심 있으면 걔가 들어가는 식
- 문제: busy waiting(=spin lock): 계속 while 문을 돌면서 / CPU와 메모리를 쓰면서 대기함.

하지만 **하드웨어적으로 test&modify를 atomic 수행**하면 간단히 해결 가능
![test and set을 통한 상호 배제](https://user-images.githubusercontent.com/50111853/154954226-8547f53d-fed3-4188-b0f9-67b62b463468.png)

## 세마포어(Semaphores)

- 프로그래머 입장에선 추상적으로 락을 걸고 풀고, 공유자원의 수를 셀 수 있으면 편하다. -> 그래서 나온 것이 세마포어!
- Semaphore S: 정수 값을 갖는 변수 / 앞의 방식들을 추상화
- S = 자원의 개수 (5면 자원이 5개 있는거)
- 추상 자료형(논리적 자료형): object, operation
- 공유 자원을 획득, 반납할때 이 처리를 담당

![세마포어](https://user-images.githubusercontent.com/50111853/154954534-b1138b44-d7c4-4e23-bcce-d4198e4c0d84.png)

**p 연산: 공유 데이터를 획득하는 과정** p연산해서 자원 가져가면 S가 1 줄어듦
**v 연산: 반납하는 과정**

### P(S): 락을 거는 과정

- while 돌다가 S가 양수가 되면(=누군가 자원을 내어놓으면) S의 값을 감소시키며(S--) 자원을 냉큼 획득.
- 계속 돌면 busy waiting과 다를 바 없다

### V(S): 자원 반납

P, V 두 연산은 atomic 연산을 통해서만 접근 가능

## Critical Section of n Processes

![p, v 연산이 있는 임계구역 알고리즘](https://user-images.githubusercontent.com/50111853/155309323-a8a0dee5-7ae2-437c-839c-d4deaa05625c.png)

### busy-wait 방식

- 프로그래머는 세마포어 지원이 되면 P, S 연산만 구현하면 된다. (추상적으로 지원)
- Sleep Lock: Block and wake up 방식 (락 없는 프로세스는 CPU를 쓰는게 아니라 아예 blocked 상태다)

![block/ wakeup implementation](https://user-images.githubusercontent.com/50111853/155310277-c83b8c1e-1f51-4a75-b95c-8f8de3ebc806.png)

L: 프로세스를 담고 있는 리스트

![스크린샷 2022-02-23 오후 8 25 11](https://user-images.githubusercontent.com/50111853/155310450-0925d238-74dd-40ce-ab1d-e30d50911e27.png)

#### P연산

- if문 안으로 못 들어가면(= 남은 자원이 없으면) S.L 리스트에 프로세스를 넣고 block 해둔다.
- 그 후 V연산을 통해 **자원이 반납되면** 리스트 중 한 프로세스를 깨워서 변수값 1 빼고 시작.

#### V연산

- 여기서 S는 자원의 개수를 세는거랑은 좀 다름. 음수면 누가 자원을 기다리고 있다. 양수면 자원을 쓰고 있다. busy-wait의 경우랑 좀 다르다.
- 자원을 내놨는데도 S의 값이 0이라는건 P연산에서 누가 -를 했다는 것
- V연산에는 자고 있는 걸 깨워주는 wakeup 함수를 포함하고 있음.

## Busy wait vs. Block/wakeup

- 보통은 block/wakeup이 더 효율적 but 프로세스의 상태를 block/wake할 때도 오버헤드 든다.
- critical section의 길이가 긴 경우 block / wakeup이 적당
- critical section의 길이가 매우 짧은 경우 busy-wait이 나을 수도 있음

## 2 Types of Semaphores

### Counting semaphore

- 세마포어 변수 값(자원의 개수)이 1 이상으로 갈 수 있을 때
- 여분의 자원 개수를 셀 때

### Binary semaphore

- 0 또는 1값만 가질 수 있는 semaphore

#### 데드락

: 둘 이상의 프로세스가 서로 상대방이 충족할 수 있는 이벤트를 무한히 기다리는 현상
![데드락](https://user-images.githubusercontent.com/50111853/155311534-bf48d4b9-dab6-4039-8db0-d9048fe4a556.png)

해결법: 자원 획득 순서를 똑같이 맞추면 됨. P0, P1 부분을 이렇게 수정하면 된다!

![데드락 해결법](https://user-images.githubusercontent.com/50111853/155312017-70fa1eff-98fe-46a2-b2d9-9f7e6e7d6127.png)


프로세스 동기화 알고리즘 (레이스 컨디션, 임계 구역, 세마포어)


미디엄의 ['how to be a 10x engineer'](https://medium.com/@_michaellin/how-to-be-a-10x-engineer-fdac2a5a1bd5)라는 글을 짧게 요약하고 내 생각을 적어본다. 

*(글에서 시니어 개발자가 10배 더 나은 개발자고 주니어 개발자는 평범한 개발자라는 느낌을 살짝 주지만, 
저자가 의도한 'junior'는 오로지 연차만을 말하는게 아닌 것 같습니다. 'junior developer'라는 단어는 '평범한 개발자'로 의역을 했습니다.)*

## 최고의 개발자?
'최고의 개발자'란 보통의 엔지니어보다 약 10배 나은 사람을 말한다.  
그들은 더 느린 속도로, 더 적은 양의 일을 할지도 모른다. 어쩌면 **코드를 치는 것보다 삭제하는데 더 많은** 시간을 쓸지도!  

### 최고의 개발자 vs. 평범한 개발자
는 바로 **소프트 스킬(non-technical skills)** 이다.  
They use the right tools, ask the right questions, and know how to prioritize.  
**그들은 적시적소에 맞는 툴을 쓰고 적절한 질문을 하며 우선순위를 매길 줄 안다.**

### 뛰어난 개발자는 적절한 도구를 찾아낸다.
“내가 8시간 안에 나무를 베어야한다면 내 도끼날을 가는데 7시간을 쓰겠다.” / 링컨

평범한 개발자는 무딘 도끼로 8시간 동안 나무를 벨지도 모른다. 뛰어난 개발자는 한 시간만에 잘 드는 전기톱을 고를 것이다. 그리고 5분 후 나무를 다 벨 것이다.  
평범한 개발자들이 자주 하는 실수는 무작정 코드부터 친다는 것이다. 그들은 자기가 아는 기술 하나로 모든 상황을 처리하려한다.

저자가 한 개발자에게 개인 웹사이트를 만들어보라고 했을 때 그는 그렇게 말했다.
"학교에서 리액트 앱 만드는 법을 배웠어서 그걸로 기초를 만들었어. 근데 이미지랑 CSS를 제대로 배치하는게 어려웠고, 
나는 배포하는 법도 몰랐어. 그래서 AWS에서 커스텀 배포를 하려고 했는데 콘솔 쓰는게 또 좀 헷갈리더라. micro 인스턴스는 뭐고 large 인스턴스는 또 뭐야?"

이때 이 개발자가 놓친 것은 이런 게 있다.  
- 요구사항 정의: 검색엔진 최적화, 댓글달기, 템플릿 등에 대한 이야기가 없음
- 대안: 그는 리액트와 AWS만 알았고 그것밖에 생각하지 못했음.

### 뛰어난 개발자는 도움을 요청한다.
몇몇은 뛰어난 개발자가 고독한 천재라는 오해를 하곤 한다. 문제를 안고 속으로 끙끙대면 해결책이 나타날 거라고 생각한다. 

팀 동료에게 질문하면 5분만에 해결될 문제를, 코드가 사골국이 될 정도로 고민하는 이들이 많다. 
그러나 **도움을 요청할 줄 아는 적은 경력의 엔지니어가 절대 도움을 요청하지 않는 능력있는 엔지니어보다 낫다.** 
도움을 요청할 땐 문제 해결에 도움이 되는 추가 맥락을 설명해주면 좋다. 예를 들어 '코드를 왜 이런 구조로 짰는지', '어디서 불러오는 API인지', '배포는 어떻게 이루어지는지' 등이 있다.

### 뛰어난 개발자는 비즈니스 가치를 이해한다.
뛰어난 개발자는 일이 일종의 투자라는 것을 안다. 그리고 그 투자로 얻는 수익은 그들이 공들인 시간보다 더 큰 가치를 가져야한다. 
기회비용을 이해하고, 구현할 수 있는 기능을 전부 구현하는게 아니라 가장 효율적이고 효과적인 기능을 추려낸다.

## 결론은 소프트 스킬이다.

**"유능하지만 재수 없는 놈(jerk)을 그냥 냅두지 마세요. 팀워크는 너무나 중요합니다."** / Netflix CEO

이외에도 결국 최강의 개발자를 결정하는 것은 바로 소프트 스킬이다. 
개발을 잘 하는 것보다 재수 없는 놈(jerk)이 되지 않는게 더 쉽다. 쓸데 없는 자존심때문에 우리의 노력이 물거품이 되지 않도록 하자. 

엔지니어는 무엇보다도 가치를 우선적으로 전달해야한다.


## 느낀 점

첫번째로 저자가 언급한 '적절한 도구 찾기'는 내가 최근 들어 가장 절실히 느끼고 있는 것이었다.  
개인 블로그를 만들면서 지킬로 했다가 리액트로 했다가 다시 지킬로 돌아왔다가... 배포를 AWS로 할까 했다가 다시 깃허브 페이지로 돌아오고... 
적절한 기술을 찾아보고 선택해서 개발을 시작하는게 무작정 시작하는 것보다 더 시간을 절약할 수 있었을 텐데 말이다. 
이제 슬슬 삽질을 줄이려고 노력해야겠다. 

그 방법은 더 많이 찾아보는 것과 기술, 배경 지식을 더 깊게 이해하는 것. 
구독하고 있는 위클리 뉴스레터들을 대충 훑을 게 아니라 흥미로운 게 있으면 들어가서 공식문서도 좀 자세히 볼 것.

또 내 블로그에도 개선하고 추가해야할 기능이 많은데, 이것들도 좀 리스트업을 해봐야겠다.
내 시간과 에너지의 기회비용을 생각하며 꼭 필요한 기능을 추가해나가자.


미디엄의 한 글을 읽고 밑줄 치고 싶었던 문장들을 적어본다.

'최고의 개발자가 되는 법'을 읽고 


## CPU Scheduling

- CPU를 어떤 프로세스에게 줄 지 결정
- CPU Job이 io bound와 cpu bound 잡이 섞여있기 때문에 필요함!
- 특히 사용자와 인터랙션 하는 IO Bound Job이 cpu 필요할 때 빨리빨리 가져야 사용자가 불편하지 않음.

## CPU Scheduling이 필요한 경우

1. running -> blocked ('나 cpu 필요없어...' io 요청하는 시스템 콜)
2. running -> ready (할당된 시간 다씀. 타이머 인터럽트)
3. blocked -> ready (io 완료 후 인터럽트. 얘한테 바로 cpu 가는거 아님)
4. terminate (프로세스가 종료됐을 때)

1,4는 자진 반납(nonpre-emtive) / 2,3은 preemtive(강제로 빼앗음)

## CPU scheduler (독립적X, 운영체제 안의 CPU 스케줄링 담당 코드)

- ready인 프로세스 중 이번에 CPU를 받을 프로세스를 고른다.

## Dispatcher

- 실제로 CPU를 주는 놈.
- context switching을 하는 놈

## 스케줄링 성능 척도

### 시스템 입장

1. CPU Utilization: CPU에 일 많이 시켜야 꿀임

- cpu를 사용한 시간 대비 일한 시간의 비율 (최대한 일 많이 해야 좋음)

2. Throughput (처리량)

- CPU Burst의 갯수. 처리 완료한 갯수  

### 프로세스 입장

1. Turnaround Time (소요시간, 반환시간)  

- cpu를 받아서 다 쓸 때까지 걸린 시간 (CPU burst 시작~끝)

2. Waiting Time (대기 시간)

- 프로세스가 기다린 시간
- pre emtive의 경우 waiting 타임이 여러차례 쌓여서 길어짐

3. Response Time (응답 시간)

- 첫번째 응답이 오는데 걸린 시간 (타임 쉐어링 환경을 위한 기준)

#### 식당 예시

cpu utilization: 요리사가 요리한 양
throughput: 처리한 손님의 개수
turnaround time: 고객이 들어와 주문하고 식사하고 나가는데 걸린 시간
waiting time: 코스요리에서 다음 메뉴 나오는 거 기다린 시간의 총합
response time: 첫번째 음식이 나올때까지 기다린 시간

## CPU 스케줄링 알고리즘

### FCFS (선착순/ First come, First Served)

- 별로 효율적이진 않다. CPU를 많이 쓰는 프로세스가 cpu를 가지면 CPU를 적게 쓰는 프로그램이더라도 기다려야 한다.
- 관여한 **프로세스의 평균 웨이팅 타임**이 길어진다.
- convoy effect: 앞에 거대한 놈이 기다리고 있어서 기다리고 있어야하는 경우를 말함.

### SJF (Shortest Job First)

- 프로세스를 사용하려는 시간 즉 CPU burst가 가장 짧은 놈에게 프로세스를 줌
- preemtive: 일단 cpu 잡으면 해당 cpu burst가 완료될 때까진 cpu를 선점하지 않음
- nonpreemtive: 현재 수행중인 프로세스의 남은 burst time보다 더 짧은 cpu burst time을 가지는 프로세스가 도착하면 cpu 빼앗아서 줌
- nonpreemtive: **shortest average waiting time**

#### SJF의 문제점

1. starvation: 어떤 프로세스에겐 CPU가 계속 안 올 수도 있다.
2. 예측이 쉽지 않음: 얼마나 CPU burst time이 필요한지 프로세스 자신도 모름

- Exponential averaging:

### Priority scheduling (우선순위)

- 우선순위가 **가장 높은** 프로세스에게 CPU를 준다
- preemtive는 더 우선순위가 높은 프로세스가 나타나면 cpu를 넘겨주고, nonpre는 넘겨주지 않음
- 작은 숫자가 우선순위가 높음.
- SJF도 일종의 priority scheduling
- Starvation의 해결법: 에이징(aging) 기법. 우선순위가 낮은 프로세스라도 오래 기다리게 되면 우선순위를 높여주자.

## 라운드 로빈

![round robin scheduling](https://user-images.githubusercontent.com/50111853/154834115-4b900873-d810-4c8b-bff2-173cbb397a53.png)

- **각 프로세스가 동일한 크기의 할당 시간(Time Quantum)**을 가짐.
- Large Q: FCFS / Small Q: 매우 빈번한 Context Switch, 시스템 성능 저하 우려
- 응답 시간이 빨라짐.
- 굳이 예측할 필요 없이 CPU를 짧게 쓰는 프로세스가 짧게 쓰고 나갈 수 있음
- **CPU를 대기하는 시간과 쓰는 시간이 비례**
- 일반적으로 SJF보다 average turnaround time이 길지만 response time은 더 짧다.

## Multilevel Queue

- ready queue를 우선순위별로 여러개로 분할, 모두 cpu 쓰려고 기다림
- 차별적임. 그래서 multilevel feedback queue를 도입

### multilevel feedback queue

![multilevel feedback queue](https://user-images.githubusercontent.com/50111853/154834381-cc5b1e4b-79d5-4a24-bbec-9f2cbfa6b1f2.png)

- foreground(interactive): 라운드로빈
- background(batch, no human interaction): 선착순
- Queue에 대한 스케줄링이 필요
  - Fixed priority scheduling: fore 부터 -> background / starvation 우려 있음
- **처음 들어온 프로세스는 우선순위 우선으로** 해줬다가 여러번 필요할 수록 우선순위가 뒤로 밀린다.

## multiple processor scheduling

![다수의 프로세서 스케쥴링](https://user-images.githubusercontent.com/50111853/154839986-bc4d10c5-9745-4d89-8aa7-803fd6b825da.png)

- cpu가 여러개면 스케줄링은 더 복잡해짐
- **load sharing**: 일부 프로세서에 Job이 몰리지 않게 부하를 공유

## real time scheduling

- real time: 정해진 데드라인 내에 끝나야함
- 미리 스케줄링을 해서 적재적소에 배치 / 주로 주기적으로 작업하는 프로세스가 많음
- hard real time systems: 반드시 데드라인 안에 끝내야
- soft real time systems: 일반 프로세스에 비해 높은 우선순위를 갖도록

## Thread scheduling

- Local 스케줄링: (user level thread가) 운영체제는 그냥 그 프로세스한테 cpu 줄지 안 줄지 결정. 어떤 쓰레드한테 줄지는 쓰레드 내부가 선택
- 글로벌 스케줄링: 커널 레벨 쓰레드의 경우, 커널의 단기 스케줄러가 어떤 쓰레드를 스케줄할지 결정

## 알고리즘 평가하는 법

![알고리즘 성능 평가](https://user-images.githubusercontent.com/50111853/154840176-a16412ec-636c-4366-8531-7feb11dcfc8b.png)

- Queueing models: 도착률과 처리율(service rate) 등으로 성능을 계산
- 구현 & 성능 측정: 실제 시스템에 알고리즘을 구현해 실제 작업의 성능 측정


CPU 스케쥴링 알고리즘의 종류와 방법 (FCFS, SJF, RR 등)


해가 바뀌고 올해엔 어떻게 공부해야하나 하는 고민을 많이 했다. 그래서 개발자 커뮤니티에서 사이드 프로젝트 팀을 찾아 들어갔고, 운영체제, 컴퓨터 구조 스터디도 매주 하고 있다.  
그럼에도 약간의 막막함은 사라지지 않던 차에, 오픈소스 강의로 유명한 Udemy에서 지속적인 성장을 하고자 하는 개발자를 위한 웨비나가 있다고 하길래 냉큼 신청했다. 듣고 느낀 점을 휘리릭 적어본다.

[Udemy 지속 성장하기 위한 개발자의 학습법](https://okky.kr/article/1154436)

## TDD의 철학으로 이해하는 피드백 주도 학습 방법 by Maker Jun 멘토

TDD란 '테스트를 먼저 만들고, 실제 코드를 작성하고, 원하는 대로 동작하는지 빠르게 피드백을 받는 것'을 말한다. 한국어로는 테스트 주도 개발이라고 한다.  
이러한 개발을 하기 위해선 **결정과 피드백 사이의 갭**을 인식하고, 그 **갭을 조절하기 위한 테크닉**이 필요하다.  
해야하는 것(결정)과 테스트 결과(피드백)의 차이를 줄여 최종적으로 해야하는 것=결과 가 되도록 만드는 것이다.  

## TDD가 필요한 이유

TDD가 필요한 이유는 딱 한 문장이 설명해준다. **"만약 내가 던진 농구공이 들어갔는지 1달 뒤에 알 수 있다면?"**  
아마도 기다리다 지칠 것이다. 어쩌면 내가 농구공을 던졌다는 사실 자체를 잊어버릴 수도 있다.  
TDD를 한다는 것은 농구골대에 공을 던져 그 공이 들어갔는지, 안 들어갔는지 바로 확인하며 코드를 짜는 것과 같다.  
Maker Jun 님은 계산기를 예로 드셨다. 

### TDD 방식대로 계산기 구현

<img src='/images/blog/2202/ds2.jpg' />

일단은 특별한 UI 없이, 계산기의 주 목적인 사칙연산이 되는 코드만 짠다.  
그리고 그 코드가 테스트를 통과한다면 다음 단계로 넘어간다.  

<img src='/images/blog/2202/ds3.jpg' />

두번째로는 최소한의 UI를 만들고 사용자 입력을 받아 이벤트 처리하는 부분을 구현한다.  
그리고 또 피드백을 하고, 덧붙이고, UI 전체 레이아웃을 잡고, 스타일을 입히고...  

테스트 개발의 핵심은 **분할 개발**이다!!!  
이런 식으로 결정과 피드백 사이의 괴리를 줄여가면 MVP(Minimal Viable Product)를 만들 수 있게 된다.

### 우리는 피드백 주도 학습을 하자!

Maker Jun 멘토님은 테스트를 먼저 만들고 개발하는 TDD처럼 우리가 피드백 주도 학습을 해야한다고 말하셨다.  
TDD처럼 나의 부족한 점을 정의하고 피드백을 해 그 약점을 고칠 수 있는 것부터 하나하나 공부를 하자는 거다!  
이 때 중요한 것은 **내가 지금 가지고 있는 지식으로 가장 작은 영역부터 해결해나가는 것**이다.

### 내가 적용할 것

가장 먼저 나는 프론트 엔드 개발을 할 때 UI부터 다뤘는데, 그러면 안된다는 것을 깨달았다.  
UI 먼저 할 게 아니라 내가 구현해야하는 것을 확실히 결정하고 테스트 코드를 기반으로 개발을 해야하는 것이었다.  
JS면 콘솔에서 가볍게 테스트를 하는 건 어떨까?  
리액트가 어떻게 돌아가는 지와 어느정도의 구현법은 잘 알지만, Redux를 자유롭게 쓰지는 못한다.  
그러면 일단 Redux의 다큐먼트를 보고 내가 모르는 부분을 찾아서 그부분부터 시작하면 되는 거다.  
중요한 건 내가 해야하는 걸 내가 해결할 수 있는 범위 내에서 최대한 잘게 쪼개는 것이었다.  
개발자로서 배워야하는 어마어마한 양의 기술과 라이브러리에 압도되곤 하는 나같은 주니어 개발자에게 꼭 필요한 조언이었다.  

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

## 개발자 : 지식의 저주 by Poco Jang 멘토

<img src='/images/blog/2202/ds4.jpg' />

대부분의 사람들은 본인이 알고 있다면 상대방도 알고 있을 것이라 생각한다.(Chip Heath의 '스틱' 중에서)  
그래서 그 지식을 공유할 필요가 없다고 생각해 기술 블로그를 잘 쓰지 않는다.   
또 "개발자로서 배워야할 것은 많은데 기술은 계속 변하잖아요. 이게 의미가 있는 건가요?"라고 묻는다.  
많이 알게 되면 내가 모르는 게 계속 보여 압도당하기도 한다.  

### 아는 만큼 보인다 

<img src='/images/blog/2202/ds6.jpg'/>

여기서 또 나오는 **메타 인지**! 내가 아는 것, 모르는 것을 잘 구분할 줄 아는게 중요하다.  
채용 공고에서 겹치는 게 **트렌드 기술**이다.

### 마음가짐의 중요성

<img src='/images/blog/2202/ds7.jpg' />

왼쪽 사진의 물컵을 보고 '반밖에 못 채웠네'라고 하는 사람이 있고 '반이나 찼네!!'라고 하는 사람이 있다.   
회사의 구인공고를 볼 때도 '난 반밖에 못 채웠네... 지원하지 말자'라고 생각하지말고, '난 반이나 할 줄 아네!'라고 생각하자.

### Poco Jang 멘토님이 말하는 것

<img src='/images/blog/2202/ds5.jpg' />

1. 컴퓨터 공학은 일종의 학문이다. 더 이상 개발을 얕보지 말자. **어려운 학문임을 인정하자.**  
2. '1시간 만에 00앱 만들기', '3개월 만에 XXX 개발자로'... 등 **인스턴트 학습의 유혹에 빠지지 말자**. 쉬워보이는 교육 컨텐츠에 익숙해져 평생 따라만 하지 말자.
3. "언젠가는 이해하겠지" 대충 넘어가지 말고 러닝 커브를 극복하자. 고통스럽지만 완벽하게 이해하도록 노력하자.
4. 지름길은 없다. 나만의 학습 로드맵을 그리자. 어차피 선택에 대한 책임은 내가 진다.
5. 모범 사례만 찾지 말고 **모범 사례가 되자.**
6. **포기할 이유를 찾지 말자.**

### 내가 적용할 것

내가 원하는 직무의 자격요건과 우대 사항 등을 보고 필요한 기술 스택, 경험의 교집합을 수집하자.  
그리고 그에 맞는 지식과 경험을 쌓자.  

### 웨비나가 끝나고

거의 2시간 진행됐는데 멘토님들이 즐겁게 진행해주시고 질문에 잘 대답해주셔서 좋았다.
들으면서 계속 나한테 하는 말 같았다. 나만의 로드맵을 그려보자!!!


더 나은 개발자가 되기 위해 나는 어떻게 공부해야할까?

개발자로서 지속 성장하기 위해서 나는 앞으로 뭘 어떻게 해야할까?


## Process Management

### 프로세스의 생성

- 부모 프로세스가 자식 프로세스를 만듦. (**트리 구조**)
- 프로세스는 자원을 필요로 함 (os로부터 받음, 부모와 공유)

### 복제 생성 (fork, exec)

- 자식 프로세스는 부모의 문맥(주소공간, 운영체제 등 자원, code,data, stack etc.)을 모두 복사
- fork: 자식이 그대로 복사. 일단 복제해놓고
- exec: 그 공간에 새 프로그램을 올림
- 자원은 공유 하기도, 안 하기도 (보통은 공유 X) 함. 공유를 해야 자원 등 절약이 가능하니까. 리눅스같은 효율적인 운영체제에서는 무작정 카피하지 않음. 스택이 달라지거나 분리가 필요할 때 **Copy-On-Write (cow). 즉, write가 발생할때 카피한다**.

### fork 코드 예시

![C언어 fork](https://user-images.githubusercontent.com/50111853/154212591-5918ba6c-ea96-453a-961b-0fdc3c967d3d.png)

- fork()한 후 반환된 pid가 새로 생기는 자식 프로세스의 pid.
- Pid로 자식/부모 프로세스 구분함. pid가 0인게 자식 프로세스
- 자식 프로세스의 경우도 부모 프로세스의 문맥(especially **프로그램 카운터)을 그대로 받기 때문에 fork()이후 코드부터** 계속 실행함. (무한루프 아님!)

### execlp 코드 예시

![C언어 exec](https://user-images.githubusercontent.com/50111853/154213451-ca76f59a-5c66-4342-ab2c-ab02ff0defa7.png)

- exec으로 덮어써서 execlp 안에 있는 함수를 실행하는 프로세스가 된다.
- 예시의 경우 리눅스 명령어임
- fork 안 하고 그냥 execlp만도 가능함

### wait

![wait 예시](https://user-images.githubusercontent.com/50111853/154214087-90459328-e68e-4712-9650-37727407008a.png)

- 프로세스를 blocked 상태로 바꿔서 잠들게 함
- 부모가 자식 프로세스가 종료되길 기다리려고 sleep

### 종료 (exit)

- 자식이 부모에게 output data를 보냄(via wait)
- 자식프로세스의 각종 자원이 os로 반납됨.

#### 종료 종류

자발적: 마지막 문장 실행 후 exit(), 컴파일러가 자동으로 중괄호 닫히는 곳(main 함수 리턴될때)에 exit 삽입
비자발적: 부모가 자식프로세스 종료(abort), 키보드로 kill or break 클릭, 부모가 종료됨

### 부모가 종료시킴 (abort)

- 자식이 할당 자원의 한계를 넘어선 경우 or 그 태스크가 더이상 필요하지 않은 경우 or 부모 프로세스가 종료되는 경우
- 자식이 무조건 부모 프로세스보다 먼저 죽는다.

fork, exec, wait, exit, abort 다 **시스템 콜**

### 프로세스간 협력 매커니즘 (Interprocess Communication, IPC)

![IPC](https://user-images.githubusercontent.com/50111853/154215397-d639f937-1832-4728-958c-0df27e3e2636.png)

- **shared memory**: 일부 주소공간을 두 프로세스가 공유 (커널한테 그 공간 쓴다고 얘기한 후에는 자기들끼리 알아서)
- **message passing**: 공유변수 일체 없이 **운영체제 커널을 통해** 메시지를 보냄.
- 1. direct: 메시지 받을 프로세스 이름을 직접 명시
- 2. indirect: mailbox 또는 port 이름을 통해 간접 전달

쓰레드는 사실상 프로세스이므로 **동일한 프로세스를 구성하는 쓰레드간 협력 당연히 가능함.**

### CPU and I/O Burst

![스크린샷 2022-02-16 오후 4 22 42](https://user-images.githubusercontent.com/50111853/154215769-6e0246a6-cd25-475f-abd3-c18162082784.png)
프로그램이 실행된다는건 CPU burst+ io burst가 반복되는 것이다.

![스크린샷 2022-02-16 오후 4 24 22](https://user-images.githubusercontent.com/50111853/154216000-0e217f07-43dc-491d-8e92-0c96fd767d79.png)

- IO-bound Job: 사람이 많이 끼어들고 **인터랙션이 많으면** io burst가 잦고 길다
- CPU-bound Job: 과학 연산 등은 주로 CPU를 많이 쓰고 CPU burst가 길다

-> **인터랙션이 많은 IO bound 잡한테 CPU를 많이 줘야 사용자가 안 답답함** -> CPU 스케줄링의 주요한 이슈

프로세스는 io bound / cpu bound 프로세스 두개로 나뉜다.

## 공부가 끝나고 느낀  점

- 부모 프로세스가 자식 프로세스를 만드는 건 알았는데 구체적인 방법과 그때 사용되는 명령어를 알게 돼서 지식이 깊어진 느낌이다.
- 지난 챕터들에서 배웠던 프로그램 카운터나 blocked 등의 개념이 이번 장에도 연결돼 나와서 엮어가며 생각해보는 맛이 있었다.


Categories