해결방법

const twoSum = (nums, target) => {
  const arr =[];
  for (let i = 0; i < nums.length; i++) {
    for (let j = i + 1; j < nums.length; j++) {
      if (nums[i] + nums[j] === target) {
        arr.push(i);
        arr.push(j);
      }
    }
  }
  return arr
}

수정

const twoSum = (nums, target) => {
  const arr = [];
  nums.forEach((num,i) => {
    nums.forEach((num, j) => {
      if (j > i && nums[i] + nums[j] === target)
        arr.push(i, j);
    })
  })
  return arr;
}

기존의 for문 대신 forEach를 사용하는 방법으로 수정해보았다. 어디선가 for문은 촌스럽다!하는 글을 보고 시도해보았지만 runtime은 3배쯤 증가하고 memory도 0.5MB쯤 더 사용하는 것을 보고 그냥 촌스럽게 써야겠다는 생각을 했다.

참고로 if 안에 j > i를 넣은 건 해당 조건을 넣지 않을 경우 중복되는 경우의 수가 나오기 때문이다.

for문을 통해 배열을 2개 놓고 하나씩 짝지어가며 비교하는 거라 O(n^2)만큼의 시간이 걸린다.

다른 풀이를 보니 hash table을 사용한 방법도 있었다. 당연하지만 나는 생각 못 했다ㅋㅋ....

해당 블로그에서 hash table을 사용한 방법을 more elegant solution이라고 말하는데 나도 곧 그런 elegant solution을 먼저 생각하는 날이 올거라 믿는다.

hash table 사용

const twoSum = (nums, target) => {
  const hash = {};
  for (let i = 0; i < nums.length; i++) {
    const otherNum = target - nums[i];
    if (hash[otherNum] !== undefined) {
      return [hash[otherNum], i];
    }
    hash[nums[i]] = i;
  }
}

for문을 한 번 쓰다보니 O(n)만큼의 시간이 걸린다. 어떤 때에 hash table을 써야하는지 다시 한 번 기억할 기회였다.

• peer란 간헐적으로 서로 연결된 host pair

• peer는 서비스 공급자가 소유하지 않고 사용자가 제어하는 데스크탑과 랩탑이다.

• 두 가지 종류
  1) a single source to a large number of peers 예) BitTorrent 2) a database distributed over a large community of peers (DHT, Distributed Hash Table)

Scalability of P2P Architectures (vs client-server architechtures)

• distribution time : 파일 복사본을 모든 N개 peer에 가져오는데 걸리는 시간
• Dcs : client-server architecture ㅊ client-server architechture에서 distribution에 도움되는 peer는 없다.
• distribution time에는 upload, download 시간, bandwidth, 병목현상으로 인한 시간 등이 포함되어 있다.
• 서버는 N개 peers에 각 파일 복사본을 전송해야한다. → NF bits를 전송. upload rate : Us, distribution에 걸리는 시간은 NF/Us.
• dmin: the lowest download rate. dmin = min{d1,dp,...,dN}.
• minimum distribution time : F/dmin
• client-server distribution time은 N이 커질 수록 distribution time이 커진다.
• P2P 아키텍쳐를 보면 각 peer는 파일 분산해서 서버를 본다. peer가 일부 파일 데이터를 수신하면 자체 업로드 용량을 사용해 데이터를 다른 피어로 재배포 할 수 있다. client-server 아키텍쳐에 비해 계산이 복잡하다. 왜냐하면 distribution time은 각 peer가 파일의 일부를 다른 peer로 배포하는 방법에 따라 달라지기 때문
• 처음에는 서버만 해당 파일을 가지고 있다. Thus, the minimum distribution time is at least F/us.
• 다운로드 속도가 가장 낮은 피어는 F/dmin초 이내에 파일의 모든 F비트를 가져올 수 없다. 따라서 최소 분포 시간은 최소 F/dmin
• 시스템 전체 업로드 용량 = 서버의 업로드 용량 + 각 피어의 업로드 용량, 즉 (총 = us + u1 + … + UN)
• Thus, the minimum distribution time is also at least NF/(us + u1 + … + uN).
• Peer-to-Peer distribution time은 N이 커져도 distribution time이 크게 커지지 않는다. → 로그함수 모양, 각 peer가 server의 역할을 분담하기 때문에.

Distributed Hash Tables (DHTs)

• client-server architecture : 하나의 중앙 서버에 모든 (key-value) pair를 저장한다.
• simple database 구현 방법 : a centralized version of this simple database. key, value pair가 포함되어 있다.
• key를 사용해서 데이터베이스에 query한다. 일치하는 key-value pair가 있으면 데이터베이스에서 해당 값을 반환한다.
• P2P에서 수백만개의 peer의 key-value 값을 저장하는 방법
  • 각 peer는 (key-value) pair 전체 중 작은 하위 집합만을 가진다. → 전체를 가지고 있지 않다.
    1. 모든 peer는 특정 key로 distributed database를 query한다.
    2. distributed database는 (key-value) pair가 있는 peer를 찾고 해당 peer는 (key-value) pair을 query한 peer로 반환합니다.
    3. 모든 peer는 새 (key-value) pair를 데이터페이스에 삽입 할 수 있다. 이런 분산 데이터베이스를 distributed hash table(DHT)라 한다.
• P2P 파일 공유 context에서 DHT 서비스 설명 :
  • key : contents 이름, value: contents 복사본이 있는 peer의 IP 주소
    • DHT 데이터베이스가 peer를 통해 분산되기 때문에 일부 peer가 'Linux' 키를 담당하며 해당 (key-value) pair를 갖게 된다. → 밥과 찰리가 각각 최신 리눅스 배포의 복사본을 가지고 있다고 하는 경우 즉, DHT 데이터베이스에는 (Linux, IPBob)와 (Linux, IPCharlie)의 두 개의 (key-value) pair 포함된다.
    • 구체적인 순서
    1. 앨리스가 'Linux' 복사본을 가지고 싶어한다고 가정 → 어떤 peer가 리눅스 복사본을 가지고 있는지 알아야함
    2. 'Linux'를 key로 DHT에 query한다.
    3. DHT는 peer인 데이브가 키 'Linux'를 담당한다고 판단한다.
    4. DHT는 peer 데이브에 연결 해 데이브로부터 (key-value) pair인 (Linux, IPBob) 및 (Linux, IPCharlie)을 가져와 Alice에게 전달한다.
    5. Alice는 IPBob 또는 IPCharlie에서 최신 Linux 배포를 다운로드한다.
• 일반적인 (key, value) pairs에 대한 DHT 설계 문제
  • (key, value) pairs을 모든 peers에 무작위로 분산시키고 각 peer가 모든 참여 peer의 IP 주소 목록을 유지하도록 하는 건 문제이다. 이런 방법은 어떤 peer가 query를 보낼 때 다른 모든 peer에 query를 보내야지만 (key, value) pairs를 포함하는 peer와 일치하는 pair를 응답받을 수 있다. 이런 방식은 확장 불가능하고 각 peer는 다른 모든 peers에 대해 알아야 할 뿐만 아니라 각 query를 모든 peer에게 전송해야하는 문제가 있다.
  • 해결 :
    • 식별자를 각 peer에 할당한다. 여기에서 각 식별자는 고정 n에 대해 [0, 2^n-1]이다. → 각 peer에 정수를 할당한다고 생각하면 된다.
    • 실제로는 위의 키 값은 정수가 아니다 → 이런 키로 정수 생성을 위해 각 키를 범위의 정수에 매핑하는 해시함수를 사용한다.
    • 해시 함수는 두 개의 다른 입력이 동일한 출력을 가질 수 있는 다대일 함수이나 해시 함수는 시스템의 모든 피어가 사용할 수 있는 것으로 가정한다. 즉, 'key'는 원래 'key'의 해시를 참조하는 것이다.
    • 예를 들어 원래 키가 "Led Zeppelin IV"인 경우 DHT에서 사용되는 키는 "Led Zeppelin IV"의 해시에 해당하는 정수
  • Distributed Hash function에 hash가 사용되는 이유
• DHT에 (key, value) pairs을 저장하는 문제
  • 가장 중요한 문제는 peer에게 key를 할당하는 규칙을 정의하는 것
  • 각 peer가 정수 식별자를 가지고 있고 각 key도 동일한 범위의 정수라는 점에서, 자연스러운 접근법은 식별자가 key에 가장 가까운 peer에 각(key, value) pairs을 할당하는 것
  • "가장 가까운" → 편의상 가장 가까운 피어를 키의 가장 가까운 후속 피어로 정의한다고 가정
  • 책 그림 참조 : n=4라고 가정 했을 때 모든 peer와 key 식별자는 [0, 15]사이에 있다. 더 나아가 식별자가 1, 3, 4, 5, 8, 10, 12 및 15인 8개의 피어가 시스템에 있다고 마지막으로 (key, value) pairs을 저장한다고 가정한다.
  • (11, 조니 우)는 8명 중에 한 명이고 가장 근접한 규칙을 사용하면 peer12가 가장 근접한 후속 peer이다. 때문에 peer12에 (11, 조니 우)를 저장한다.
  • 앨리스는 열쇠에 가장 가까운 피어를 어떻게 결정할까? : 앨리스는 시스템의 모든 peer(peer ID 및 해당 IP주소)를 추적해야하는 경우 가장 가까운 피어를 로컬로 확인할 수 있다. 하지만 이런 방식의 경우 각 피어가 DHT의 다른 모든 피어를 추적해야하며 이는 비현실적이다.

Circular DHT

• peer가 원형으로 되어 있다고 생각하자. 방향은 오른쪽.
• 순환 배치에서 peer는 자신의 직전 peer와 직후 peer만을 알고 있다. 아깡의 예를 보면 peer5sms peer 8과 peer 4만을 알고 있다. 이런 peer의 순환 배치는 overlay network의 특수한 경우이다. peer는 물리적 링크, 라우터 및 호스트로 구성된 'underlay' 컴퓨터 네트워크 위에 상주하는 추상 논리적 네트워크를 형성하지만 overlay network는 링크의 물리적 링크가 아닌 peer pairs 간의 가상 연결을 의미한다.
• peer3이 key 11을 찾을 때 peer3은 메시지를 시계방향으로 돌린다. 피어가 이런 메시지를 받을 때마다 직전, 직후 식별자(peer)만을 알기 때문에 해당 key에 대한 책임이 있는지(가장 가까운지) 여부를 판단 할 수 있고 책임지지 않는 경우 그냥 메시지를 다음으로 넘긴다. 이는 key 11에 가장 가까운 peer 12에 전달 될 때까지 지속된다.
• circular DHT는 각 peer가 관리해야하는 overlay 정보의 양을 줄여준다.
• 하지만 최악의 경우 각 피어가 인접한 두 피어만 알고 있지만 키를 담당하는 노드를 찾기위해 DHT의 모든 N 노드가 원을 중심으로 메시지를 전달해야 할 수도 있다. (N/2 메시지).
• 이를 해결하기 위해 'shortcut'이 있다. 각 peer는 직전, 직후의 peer뿐만아니라 근접한 다른 peer를 추적한다. 'shortcut'는 query message의 routing이 신속하게 이루어지도록 사용된다.

Peer Churn (피어 변동)

• peer는 임의로 탈퇴하거나 가입할 수 있다.
• 이를 위해 각 peer는 두 개의 후속 peer의 IP address를 알고 있어야한다.
• 후속 peer 중 하나가 이탈하면 그 다음의 peer에 대한 IP address를 가지도록 업데이트한다.
• 각 peer는 두 후속 peer들이 살아 있는지 확인을 위해 주기적으로 ping messages를 보낸다.

• hostname : internet host 식별자 예) www.yahoo.com 하지만 이런 hostname은 인터넷 내의 위치 정보를 제공하기에는 빈약하다. 게다가 hostname은 다양한 길이의 알파벳 철자를 포함하기 때문에 routers에서 처리하기 힘들다. → hosts는 IP addresses에의해 식별된다.
• IP addresses : 4바이트로 구성되며 계층구조가 견고하다. 각 마침표는 0 - 255까지의 십진수 표기법으로 표현된다. IP addresses는 계층적이다. 왼쪽에서 오른쪽으로 스캔하며 인터넷에서 host가 위치한 위치에 대해 구체적인 정보를 얻는다.

Services Provided by DNS

• host를 식별할 때 두가지 방법 : hostname과 IP address

• 사람 : hostname, routers : IP address

• DNS(domain name system) : hostname을 IP address로 변환하는 일을 한다.

  1. DNS의 계층으로 구현된 분산 데이터베이스이다.
  2. hosts가 분산 데이터베이스에 쿼리할 수 있게 하는 application-layer protocol이다.

• DNS 서버는 berkeley internet name domain(BIND) 소프트웨어를 실행하는 유닉스 시스템인경우가 많다. DNS protocol은 UDP를 통해 실행되며 port 53을 사용한다.

• DNS는 hostname에서 IP address로 변환하기 위해 HTTP, SMTP, FTP와 같은 다른 application-layer protocol에서 사용된다.

• 과정

  1. 동일한 유저 시스템이 DNS application의 client 측을 실행한다.
  2. 브라우저는 URL에서 hostname을 추출해 DNS application의 client 측으로 hostname을 전달한다.
  3. DNS client는 DNS server로 hostname이 포함된 query를 보낸다.
  4. DNS client는 hostname에 대한 IP address가 포함된 응답을 받는다.
  5. DNS로부터 IP address를 받은 후 브라우저는 해당 IP address의 port 80번에 해당하는 HTTP server process에 TCP connection을 시작한다.

• IP address는 종종 근접한 DNS server에 caching 되기 때문에 DNS 네트워크 트래픽과 평균 DNS 딜레이를 줄이는데 도움을 준다.

• DNS는 hostname에서 IP address를 변환하는데 추가적인 중요 서비스를 제공한다.

  • Host aliasing(별칭) : 복잡한 hostname은 하나 이상의 별칭을 가질 수 있다. relay1.west-coast.enterprise.com →

  • canonical hostname(정식 호스트이름) :** *enterprise.com and www.enterprise.com , DNS는 application 호출로 제공된 별칭 호스트 이름과 호스트의 IP 주소를 가져 올 수 있다. 순서: host alias name > host canonical name > IP address

  • Mail server aliasing(메일 서버 별칭) :host의 IP address뿐만 아니라 제공된 alias hostname를 위한 canonical hostname을 가져오기 위해 mail application에서 DNS를 호출 할 수 있다.
    예) heathers@nextunicorn.kr에서 nextunicorn.kr이 도메인 이름이기에 이를 이용해 서버의 IP 주소를 찾아 TCP 연결

  • Load distribution : DNS는 복제된 웹 서버 간에 load distribution을 수행하는데도 사용된다. cnn.com과 같은 사이트는 여러 서버를 통해 복제되고 각 서버는 서로 다른 end-system에서 실행된다. 그렇기에 복제된 웹 서버는 IP 주소 집합이 하나의 표준 호스트(canonical hostname)과 연결된다. DNS database에는 이 IP address 집합이 포함되어 있다. client가 주소 집합에 매핑된 이름에 대해 DNS query를 만들면 server는 전체 IP 주소 집합에 매핑된 이름에 대해 DNS query를 만들면 서버는 전체 IP 주소 집합으로 응답하지만 각 응답 내의 주소 순서를 회전한다. client는 일반적으로 HTTP 요청 메시지를 집합에 먼저 나열된 IP address로 전송하므로 DNS 순환은 트래픽을 복제된 서버 간에 분산시킨다 → 동일 도메인 주소에 접근하는 client들에게 IP 주소를 분산시킨다 일반적으로 DNS 서버에는 하나의 도메인의 여러 IP 주소 List를 가지고 있다. 접속하는 client들에게 이 list를 모두 주는데 보통 첫번째 주소를 사용하기 때문에 서버가 list를 rotation해서 보내준다.

    Overview of How DNS Works

  • hostname-to-IP-address translation service

  • DSN가 하나로 구성되어 있다면 client가 요청하거나 DNS가 응답할 때 편할 것이다. 하지만 오늘날에 맞지 않음

  • 중앙화된 설계의 문제점 :

    • single point of failure : DNS server가 다운되면 모든 인터넷도 다운된다.
    • traffic vlume : 하나의 DNS server에서 모든 query에 응답하게 된다.
    • distant centralize database : 물리적인 거리가 멀면 delay가 심화된다.
    • maintenance : DNS server가 하나라면 매일 새로운 host를 업데이트되어야 한다.

    A Distributed, Hierarchical Database

  • scale문제를 해결하기 위해 DNS는 전 세계에 분산된 수많은 계층적 형태의 서버를 사용한다.

  • mapping은 DNS servers에 분산되어 있다.

  • DNS servers는 3계층이 있다.

    • root DNS servers
    • TLD(top-level domain) DNS servers
    • authoritative DNS servers

  • 예) www.amazone.com 찾기

    1. client는 root server에 접근해 TLD server(.com)의 IP주소를 받는다.
    2. client는 TLD server에서 authoritative server(amazon.com)의 IP 주소를 받는다.
    3. clicent는 authoritative server(amazon.com)에서 www.amazone.com의 IP 주소를 받는다.

  • Root DNS servers : 전 세계에 13개가 있다.

  • Top-level domain (TLD) servers : 이 서버들은 com, org, net, edu, gov 등의 신뢰할만한 TLD, uk, fr, ca, kr 등의 국가 TLD 등이 있다.

  • Authoritative DNS servers

  • DNS server의 또 다른 중요한 타입 : local DNS server(a default name server)

    • 서버의 계급에 엄격히 따르지 않는다. 대신 DNS 구조에도 중앙화로 되어있다. 각 ISP(학교, 회사 등)이 local DNS server를 가진다.
    • host가 DNS query를 만들 때 query는 local DNS server로 보내지고 proxy처럼 역할을 하며 query를 DNS server 계층으로 전달한다.
    • DNS name resolution example
      • recursive queries: 기본
      • iterated query: local DNS server에 따라

DNS Caching

• DNS caching
• 장점 : delay를 줄임, DNS message 수를 줄임(traffic 낮춤)
• hostname/IP address pair가 DNS server에 cache되고 동일한 hostname을 가진 다른 query가 DNS server에 도착하면 DNS server는 hostname에 대한 권한 없이도 원하는 IP address를 제공한다.
• local DNS server는 TLD 서버의 IP 주소도 cache 할 수 있기 때문에 local DNS server는 query chain을 우회할 수 있고 일반적으로 우회한다.
• 단, cache한게 오래되어 있을 수 있다. 만약 name host의 IP address가 변경되었다면 TTL(Time to live)이 만료될 때까지 인터넷 전체는 알 수 없다.

DNS Records and Messages

• DNS server는 hostname과 IP address mapping을 제공하는 RR(resource record)을 포함해 DNS distributed database store resource records(RRs)를 함께 구현한다.
• resource record(RR) 형태 : (name, value, type, TTL)
  • TTL: time to live of the resource record, cache에서 리소스를 제거할 시기를 결정한다.
• query와 reply 메시지 형태는 같다.
• nslookup 은 name server 관련한 조회를 할 수 있는 명령어

• mail system의 주요 component: user agents(UA), mail servers, Simple Mail Transfer Protocol(SMTP)
• Outgoing message queue : 발신 문자 대기열
• mailbox는 mail server 중 하나에 위치해있다.
• 메일서버로 메일 전송을 못 할 시 message queue(메세지 대기열)이후에 주기적으로 전송시도를 한다. (30분 정도마다) 며칠동안 실패하면 서버는 메시지를 삭제하고 발신자에게 메시지로 알린다.
• SMTP는 인터넷 전자 메일을 위한 애플리케이션 계층 프로토콜이다. 발신자로부터 수신자에게 메일 전달을 위해 TCP의 믿을만한 데이터 전송 서비스(reliable data transfer service)를 사용한다.
• client와 server 측을 가지고 있다.

SMTP

• http보다 오래되었다.

• 메일 메시지의 header뿐만 아니라 body도 7-bit ASCII로 제한된다. 80년대에는 대용량 이미지 등을 메일로 보내지 않았기 때문에 적합한 형태였다. 그렇기에 오늘날 멀티미디어 전송을 위해 몇 가지 과정을 더 거쳐야 한다.

  1. 이진 멀티미디어 데이터를 ASCII로 인코딩

  2. SMTP 전송

  3. 해당 ASCII 메시지를 다시 이진수로 디코딩

     → 이에 비해 HTTP는 전송 전에 멀티미디어 테이터를 ASCII로 인코딩할 필요가 없다.

• SMTP 과정

  1. 앨리스가 자신의 user agent를 호출 후 밥의 주소(IP address) 제공 및 메시지 작성, 발신 지시
  2. 앨리스의 user agent는 메시지를 앨리스의 mail server로 보낸다. 메시지는 message queue에 놓이게된다.
  3. SMTP의 client 측인 앨리스의 mail server는 message queue에 담긴 message를 확인하고 SMTP server에 TCP connection을 연다.
  4. 초기 SMTP handshaking 후 SMTP client는 앨리스의 메시지를 TCP connection으로 전송합니다.
  5. 밥의 mail server인 SMTP의 서버측은 메시지를 수신합니다. 이후 밥의 메일 서버는 밥의 mailbox에 메시지를 놓습니다.
  6. 밥은 원할 때 그의 user agent를 호출해 메시지를 읽습니다.

• 중요점

  1. 일반적으로 SMTP는 두 메일 서버가 세계 반대쪽에 위치하더라도 중간 mail server를 사용해서 메시지를 보내지 않는다는 점이다. TCP connection은 두 server를 direct로 연결한다.
     • 만약 밥의 server가 down되면 메시지는 앨리스의 mail server에서 계속 전송 시도를 한다.
     • SMTP는 사람의 면대면 만남과 흡사하다. 첫 handshaking은 서로 인사를 하는 과정이며 이 때 SMTP client는 발신인의 이메일 주소와 수신자의 이메일 주소를 표시한다.
     • SMTP는 TCP를 통해 메시지를 에러없이 전달한다.
  2. SMTP는 persistent connection을 사용한다.
     • 만약 같은 mail server에 여러 메일을 보낼 경우 같은 TCP connection을 사용해서 보낸다. 이 때는 client에서 MAIL FROM: 을 사용해서 각각이 독립된 메일임을 알려준다.
  3. SMTP는 CRLF를 사용한다.
     • CRLF : CR(carriage return) + LF(line feed)이다. 텍스트의 한 줄이 끝남을 표시하는 문자 또는 문자열을 의미하며 특수문자로 눈에는 보이지 않는다. 개행문자, 줄바꿈 문자, EOL(end-of-line)과 같은 뜻이다. 기종이나 운영체제에 따라 새줄 문자를 나타내는 코드가 다를 수도 있기에 텍스트를 다른 시스템으로 전송할 때 새줄 문자의 치환작업도 필요한다.
     • LF : 아스키 코드 16진수로 OA, 기능은 커서를 현재 행의 다음 행으로 즉, 아래로 내리기
     • CR: 아스키 코드 16진수로 OD, 기능은 커서를 현재 행을 맨 좌측으로 옮기기 즉, '커서를 아래로 내리는 동작' + '커서의를 행의 맨 앞으로 보내는 동작' = '다음줄로 행갈이' 사용 :
     • 도스/윈도우는 CR+LF로 하나의 행길이,
     • 유닉스/리눅스: LF로 하나의 행갈이,
     • 맥에서는 CR로 하나의 행갈이 표현,

HTTP와 비교

• HTTP는 web server에서 web client로 파일을 전송한다. SMTP는 메시지를 mail server에서 mail server로 전송한다.
• HTTP는 pull protocol이다. SMTP는 push protocol이다. 그렇기에 HTTP의 TCP connection은 파일을 받는 쪽에서 시작하고 SMTP의 TCP connection은 파일을 보내는 쪽에서 시작한다.
• 이미지 파일등의 binary data를 보낼 때 HTTP는 인코딩 과정이 필요 없지만 SMTP는 ASCII 코드로 인코딩 과정이 필요하다.
• HTTP는 각각의 객체를 자체 HTTP 응답 메시지에 캡슐화를 한다. SMTP는 메시지의 모든 객체를 하나의 메시지에 넣는다.

Mail Message Formats

• SMTP에는 header와 body가 있고 header에는 지엽적인 정보가 들어간다. 이런 형식은 RFC에서 지정하고 있다. header에는 From:, To:와 같은 내용이 들어가고 subject: 와 같은 옵션도 있다.
• 이러한 header의 형식은 SMTP command의 MAIL FROM, RCPT TO와 같은 command과 다르다. 여기서의 format은 메일의 형식이다.
• header의 아래에는 빈 줄이 있고 그 아래에 body가 있다.

Mail Access Protocols

• 위의 예시들은 밥이 자신의 mail server에 로그인을 해서 메일을 읽는다고 가정했다. 하지만 오늘날에는 client-server architecture를 사용한다. 즉, 일반적인 사용자는 PC, 노트북, 스마트폰 등 다양한 end system에서 메일을 읽는다.

• 위에서 만약에 밥의 mail box가 그의 local PC에 있다면 밥은 메일을 받기 위해서 항상 PC가 켜진채로 인터넷에 연결되어 있어야 한다. 하지만 대부분의 사용자는 local PC에서 상시 공유 메일 서버에 저장된 편지함에 접근합니다. 이 mail server는 다른 사용자와 공유되고 일반적으로 사용자의 ISP에서 관리한다.

• SMTP의 사용은 발신자 → 발신자의 mail server → 수신자의 mail server → 수신자의 과정에서 사용됩니다. 발신자가 굳이 발신자의 mail server로 보내는 이유는 만약 수신자가 연결 될 수 없는 상태일 경우에 server가 주기적으로 메시지 전송을 하기 위함이다.

• 위의 과정에서 수신자의 mail server → 수신자의 경우 SMTP를 사용하지 않는다. SMTP는 push protocol이기 때문이다. 대신 메일에 접근 할 수 있는 protocol을 사용한다. 주로 POP3(post office protocol - version3), IMAP(internet mail access protocol), HTTP가 사용된다.

  

  

POP3

• 기능적으로 제한되어 있어 짧고 읽기 쉽다.
• user agent에서 mail server로 110번 포트를 사용해서 TCP connection을 연다. 이후 3단계를 거친다. 인증(authorization), 트랜잭션(transaction), 갱신(update)단계이다.
• 인증 : 유저 인증을 위해 username과 password를 보낸다. 두 가지 command가 있는데 user , pass이다.
• 트랜잭션 : user agent는 메시지를 가져온다. 이 때 user agent는 삭제를 위해 메시지에 표시하고 삭제마크를 지우고 메일 통계를 가져온다.
  response는 두가지로 +OK, -ERR가 있다. 'download and delete' 또는 'download and keep'으로 구성할 수 있다. user agent가 작동중인 모드에 따라 달라진다. download and delete 모드에서는 UA가 list, retr, dele command를 실행한다.
• 갱신 : client에서 QUIT command를 실행한 후 갱신하고 POP3를 종료한다. 이 때 mail server에서는 삭제 표시 된 메시지를 삭제한다.
• UA는 먼제 mail server에 저장된 메시니의 각 크기 별로 나열하도록 요청한다. 이 후 UA는 mail server에서 각 메시지를 검색하고 삭제한다. quit command 이후 POP3 서버는 갱신단계로 들어가 읽은 메시지를 삭제한다.
• 문제 : download-and-delete 모드의 문제는 수신자인 bob이 PC, 노트북, 휴대폰 같은 다양한 end system에서 메시지에 접을 하고 싶을 때 다른 컴퓨터를 사용해서 다시 메일을 읽고 싶을 때 메일을 읽을 수 없다는 점이이다.
• download-and-keep 모드의 경우 밥은 여러 컴퓨터에서 메일을 다시 읽을 수 있다.
• POP3 세션동안 UA과 mail server는 일부 정보 상태를 유지하고 삭제된 것으로 표시된 유저 메시지를 추적할 수 있다. 하지만 POP3 서버는 POP3 세션 전체에 상태정보를 전달하지 않는다. 이렇게 전반적으로 상태정보가 부족하면 POP3 서버 구현이 크게 간소화 된다.

IMAP

• POP3는 로컬에서 폴더를 만들어 관리 할 수는 있으나 원격에서 모든 컴퓨터로 접근 할 수 있는 폴더 계증을 유지하지는 못한다. 즉, 사용자가 원격 폴더를 만들고 메시지를 할당하는 수단을 가지지 않는다. IMAP는 이를 해결하기 위해 나왔다.
• IMAP 서버는 각 메일를 폴더와 연결한다. 처음 메시지가 왔을 때 서버는 수신자의 INBOX 폴더와 연결한다. IMAP는 유저에게 폴더를 생성하고 메시지를 옮길 수 있으며 원격 폴더에서 특정 기준과 일치하는 메시지를 찾을 수 있는 command를 제공한다.
• POP3과 다르게 IMAP는 IMAP 세션 전체에 유저의 상태 정보를 유지한다. 예를 들면 폴더 이름과 폴더와 관련된 메시지가 표시된다.
• IMAP의 또다른 특징은 UA가 메시지 구성요소를 가져 올 수 있는 command를 가지는 것이다. 예를 들면 UA는 메시지의 header나 MIME 메시지의 일부만 가질 수 있다. 이는 a low-bandwidth connection(저대역폭 연결)에 유용하다. 이는 유저가 느린 속도로 메시지의 모든 정보를 받지 않기를 원할 때 일부만 받아서 볼 수 있다.

Web-based E-mail

• 많은 유저는 웹 브라우저를 이용해 메일을 보내고 접근한다. 이 말은 대부분의 UA는 보통 웹 브라우저이고 HTTP를 통해 원격 mailbox과 상호작용한다는 것이다.
• 그렇기에 대부분의 경우
• 발신자 UA → 발신자 mail server : HTTP 발신자 mail server → 수신자 mail server : SMTP 수신자 mail server → 수신자 UA : HTTP* 로 이루어진다.

• 작은 규모의 자율적인 서비스로 구성
• 각 서비스는 독립적이며 단일 비즈니스로 구성
• 작은 개발팀이 개발 할 수 있는 개발 코드베이스
• 서비스는 해당 데이터나 외부 상태 유지
• 각 서비스의 내부 구현 사항은 외부 서비스에서 가려짐
• 다중저장소 프로그래밍을 지원 -> 각 서비스는 개별 라이브러리 등 사용가능

-** API 게이트웨이** : API 게이트웨이는 클라이언트의 진입점입니다. 클라이언트는 서비스를 직접 호출하는 대신, 호출을 백 엔드의 적절한 서비스에 전달하는 API 게이트웨이를 호출

• 장점 :
  • 클라이언트와 서비스가 분리
  • 서비스가 웹 우호적이 아닌 AMQP 등의 메시징 프로토콜을 사용 가능, API 게이트웨이는 인증
  • 로깅, SSL 종료, 부하 분산 등의 다른 교차 기능을 수행 가능
  • 제한, 캐싱, 변환 또는 유효성 검사와 같은 즉시 사용 가능한 정책

마이크로 서비스 아키텍쳐 특징

• 장점
  • 민첩성
  • 집중화된 소규모 팀
  • 소규모 코드 기준
  • 기술의 혼합
  • 결함 격리
  • 확장성
  • 데이터 격리
• 단점
  • 복잡성
  • 개발 및 테스트
  • 통제 부족
  • 네트워크 정체 및 대기 시간
  • 데이터 무결정
  • 관리
  • 버전 관리
  • 기술 수준

• 소프트웨어 디자인 패턴(소프트웨어 디자인 설계) : 소프트웨어 공학의 소프트웨어 디자인에서 특정 문맥에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책이다.(wiki) 즉, 소프트웨어 설계 시 특정 문제를 반복해서 해결할 때 재사용할 수 있는 해결책을 의미한다. 주로 생성 패턴, 구조패턴, 행위 패턴 3가지로 나눈다.

싱글톤 패턴(singleton pattern)

• 자바에서 많이 사용하는 패턴
• 생성 패턴의 하나이다.
• 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 패턴
• 싱글톤 패턴의 클래스는 생성자가 여러 차례 호출되어도 실제로 생성되는 객체는 하나이며 최초 생성 이후 호출된 생성자는 최초의 생성자가 생성한 객체를 리턴한다.
• 애플리케이션이 시작될 때 어떤 클래스가 최초 한번만 메모리를 할당하고(Static) 그 메모리에 인스턴스를 만들어 사용하는 디자인패턴. 즉, 생성자의 호출이 반복적으로 이뤄져도 실제로 생성되는 객체는 최초 생성된 객체를 반환한다.

장점

• 메모리 낭비를 줄일 수 있다. : 최초 한 번만 메모리 할당 이후 한 번의 인스턴스 생성으로 재사용 가능 하기 때문
• 다른 클래스의 인스턴스들이 데이터 공유하기가 쉽다. : 싱글톤 클래스의 인스턴스는 전역 인스턴스 이기 때문

단점

: 싱글톤 인스턴스가 전역성을 띄면서 생기는 문제이다.

• 싱글톤 인스턴스가 너무 많은 일을 하거나 많은 데이터를 공유 할 경우 다른 클래스의 인스턴스와 결합도가 높아져 객체 지향 설계 원칙의 '개방-폐쇄 원칙'에 어긋 날 수 있다.

• 수정, 테스트가 어려워진다.

• 싱글톤 객체 수정으로 사이드 이펙트가 생길 수 있다.

• 멀티 쓰레드 환경에서 동기화처리 문제가 생긴다. (인스턴스가 2개 생성 된다는 등의 문제)

출처

• https://elfinlas.github.io/2019/09/23/java-singleton/
• https://gmlwjd9405.github.io/2018/07/06/singleton-pattern.html

• 함수 선언식(function declaration) : 호이스팅에 영향 받음

  function sum(a, b) {
  return a + b;
  }

• 함수 표현식(function expression) : 호이스팅에 영향 받지 않음
• 익명 함수 : 이름이 없는 함수, 변수에 익명함수를 할당하거나 다른 함수의 매개변수로 사용가능하다. 코드를 보면 sum변수에 익명함수가 할당 되어 있다.

  var sum = function() {
  return a + b;
  }

• 스코프(scope) : 어떠한 식별자(변수)에 접근 할 수 있는 범위
• 클로저(closur)
  • 어떤 함수(외부함수)에서 선언한 변수를 참조하는 내부함수에서만 발생하는 현상
  • 외부 함수의 LexicalEnvironment가 가비지 컬렉팅되지 않는 현상
• 1급 시민(first-class citizen) : 1급 시민의 *조건 *
  • 변수(variable)에 담을 수 있다
  • 인자(parameter)로 전달할 수 있다
  • 반환값(return value)으로 전달할 수 있다
• 1급 객체(first-class object) : 1급 시민의 조건을 가진 객체
• 1급 함수(first-class function) : 1급 시민의 조건을 갖춘 함수, JavaScript에서는 함수도 객체이기 때문에 JavaScript의 함수는 1급 객체이자 1급 함수이다.
• 함수의 실행 : 함수뒤에 ()가 있으면 실행의 의미이다.

1. IIFE 즉시 실행 함수

IIFE(Imemediately-invoked function expression)는 정의된 즉시 실행되는 자바스크립트 함수이다.

목적

• 로컬 블록 내에서 지역 변수 호이스팅을 방지
• 글로벌 네임스페이스의 오염을 방지 : IIFE는 익명함수를 사용할 수 있기 때문
• 함수 내 정의된 변수에 대한 프라이버시를 유지하면서 동시에 메서드에 대한 공개 액세스를 허용 (from Wiki)

간단하게 말하면 주로 private scope를 만들기 위해 IIFE를 사용한다.

즉, 함수 내에서 변수를 선언해 함수의 스코프를 함수 내로 제한하고 즉시 함수를 실행시키면서 함수명에 의한 호이스팅(함수 선언식 사용 시)이나 전역 변수 오염을 막음으로서 예상치 못한 버그, 에러 등을 예방할 수 있다. ES6 이전에는 모듈화를 할 때 IIFE 패턴을 많이 사용했다고 한다.

코드 예시

1번

• ()안에 익명함수를 선언하고 ()를 밖에 사용해 즉시 실행한다.

  (function() {
  console.log('IIFE');
  })();
  

(()=> { console.log('IIFE arrow function') })()

- 에러 : 익명함수를 반드시 ```()```로 감싸야한다. 

function() { console.log('no wrapping parentheses') }() // error

### 2번
- 함수 실행을 의미하는 ```()```가 내부에 있다.

(function() { console.log('IIFE'); });

(()=> { console.log('IIFE arrow function') }())

### 3번
- 이름이 있는 IIFE

(function callIIFE() { console.log('named IIFE'); })();

```

2. IIFE 꼭 알아야하나?

이 부분이 가장 의문이었다. 이전에 IIFE에 대해 처음 알게되었을 때 ES6의 등장으로 잘 사용할 일이 없다는 글을 보았었다. 하지만 어디에나 레거시 코드가 있고 괄호()로 감싸져있는 함수를 볼 때마다 낯설게만 느껴졌다. 현 직장의 코드에서는 IIFE를 본 적이 없으나 비슷한 개념으로 사용하고 있는 부분들이 있어서 처음 해당 코드를 볼 때 IIFE가 생각나지 않아 한참이나 헤맸었다. 게다가 검색을 하다보면 IIFE를 사용한 코드 예시가 아주 드물지만 있어서 뭔지는 알아야겠다고 생각했다. 과거와 항상 함께하는 한 알아야할 지식이라고 생각한다.

용어

• 네임 스페이스 (name space) : 구분이 가능하도록 정해놓은 범위나 영역. 이름을 한 곳에 모아 충돌을 방지하고 해당 이름으로 선언된 변수는 함수를 쉽게 가져다 쓸 수 있다록 만든 메커니즘. ❗️ 네임 스페이스 패턴(name space pattern)을 검색하면 더 확실히 알 수 있다.

1. ReactElement

React.element는 type과 props를 가진 객체이다.

type Key = string | number

interface ReactElement<P = any, T extends string | JSXElementConstructor<any> = string | JSXElementConstructor<any>> {
  type : T;
  props : P;
  key: Key | null;
}

2. ReactNode

ReactNode는 ReactElement, ReactFragment, string, number, ReactNode의 Array, null, undefined, boolean이다.

type ReactText = string | number;
type ReactChild = ReactElement | ReactText;

interface ReactNodeArray extends Array<ReactNod> {}
type ReactFragment = {} | ReactNodeArray;

type ReactNode = ReactChild | ReactFragment | ReactPortal | boolean | null | undefined;

3. JSX.Element

JSX.Element는 props와 type이 any인 제네릭 타입을 가진 ReactElement이다. JSX는 글로벌 네임 스페이스에 있기 때문에 다양한 라이브러리에서 자체 라이브러리의 방법대로 실행 될 수 있다.

리액트의 경우 다음과 같이 실행된다.

declare global {
  namespace JSX {
    interface Element extends React.ReactElement<any, any> {}
  }
}

예시

<p> // ReactElement = JSX.Element
  <Custom> // ReactElement = JSX.Element
    {true && 'test'} // ReactNode
  </Custom>
</p>

4. Class component와 Functional component의 render 시 return 값 차이

• Class Component는 ReactNode를 return

  render(): ReactNode;

• Functional Component는 ReactElement를 return
• Functional component는 _stateless components_이다.

  interface StatelessComponent<P = {}> {
  (props: P & { children? : ReactNode }, context?: any): ReactElement | null;
  }

5. 그래서 타입 선언 시 Class component와 Functional component는 어떻게 다를까?!

✏️ Class Component는 ReactNode를 타입으로 지정한다. ReactNode는 그 자체로 다양한 타입을 지니기 때문에 충분! ✏️ Functional Component는 ReactElement는 object 형태로 null 값을 가지고 있지 않기 때문에 union을 사용해서 null 값을 줘야한다. 💯 ReactElement | null

const Example = () : ReactElement | null => {
  if(condition) {
    return null;
  };

  return <h1>Hello World</h1>
};

css를 사용하면서 반복적인 실수를 할 때가 있다. 이번에도 이전에 했던 실수를 또 하게 되었다. 앞으로 이 포스팅에 반복되는 실수(?)들을 하나씩 채워나갈 생각이다.

1. transform: scale(0.5)을 통한 크기 변환

원래 element의 크기가 width: 100px, height: 100px 이라면 transform: scale(0.5)적용 시 width: 50px, height: 50px로 크기가 줄어든다. 여기서 중요한 점은 기존 공간을 유지 한 채 크기가 줄어든다는 것이다!

보면 transform : scale(0.5)를 사용한 경우 div안의 글자크기도 함께 줄어들었지만 원본 크기만큼의 공간을 유지한 채 크기가 줄어들었다. 왜냐하면 원본크기는 여전히 width: 100px, height:100px이기 때문

하지만 width, height를 이용해 크기를 줄였을 때는 원본 자체가 5050이 된 것이기 때문에 100100만큼의 공간이 남지 않는다.

이게 왜 중요하냐면 위쪽에 margin-top : 12px을 줄 때 transform: scale(0.5)로 크기 조정을 했을 경우 실제로는 12px + α만큼의 margin이 생겨 생각과는 다른 위치에 element가 있을 것이기 때문

미리 알아야 하는 단어

• 일급 함수(first-class function) : 함수를 다른 변수와 같이 다룰 수 있는 함수를 말한다. 예를 들면 함수를 다른 함수의 인자로 넘길 수 있고 다른 함수로 반환할 수 있다. 당연히 변수에 함수를 할당하는 것도 가능하다.
• 고차 함수(higher-order function, HOF) : 함수를 인자로 전달 받거나 함수를 결과로 반환하는 함수.
• 고차 컴포넌트(higher-order component, HOC) : 리액트 컴포넌트를 재사용하기 위한 기술. 컴포넌트를 가져와서 새 컴포넌트를 반환하는 기술이다.
• 참조 평등(Referential equality) : 참조 평등은 두 객체에 대한 포인터가 동일하다는 것을 의미한다. 즉, 두 객체는 같은 메모리 위치에 포함되어 포인터가 동일한 객체를 참조하는 것을 알 수 있다. (===와 ==)

1. 리액트 공식홈페이지 정의

1) useCallback

const memoizedCallback = useCallback(
  () => {
    doSomething(a, b);
  },
  [a, b],
);

메모이제이션된 콜백을 반환한다. 메모이제이션된 콜백은 콜백의 의존성(dependency)이 변경되었을 때만 변경된다.

2) useMemo

const memoizedValue = useMemo(() => computeExpensiveValue(a,b), [a,b]);

메모이제이션된 값을 반환한다. 의존성(dependency)가 변경되었을 때만 메모이제이션된 값을 다시 계산한다. 이를 통해 불필요한 연산을 피한다. useMemo로 전달된 함수는 렌더링 중에 실행된다! side effect는 useEffect에서 하는 일이고 useMemo에서 하는 일이 아니다. 의존성 배열에 아무 것도 없으면 매 랜더링마다 새 값을 계산한다.

useCallback(fn, deps)은 useMemo(() => fn, deps)와 같다.

2. 사전 지식

1) 일급 함수(first-function)

함수를 다른 변수와 같이 다룰 수 있는 함수를 말한다.

const number = 1;
const greeting = 'hello';
function foo() {
  return 'bar';
}

// 변수에 할당한 함수
const otherFoo = function() {
  return 'bar';
}
// 변수에 할당한 함수(Arrow Function)
const anotherFoo = () => 'bar';

number;
greeting;
foo();
otherFoo();
anotherFoo();

함수를 변수에 할당할 수 있으면 어떤 것들을 할 수 있을까?!

• 다른 함수의 인자로 사용하기
• 함수의 반환값으로 사용하기 (함수의 반환 값이 함수가 될 수있기에)
• 객체의 키 값으로 사용하기
• 배열의 값으로 사용하기
• Map 객체의 키로 사용하기

2) 고차 함수 (Higher-order function)

함수를 인자로 전달 받거나 함수를 결과로 반환하는 함수. ** 다음의 실행 값이 무엇이 나올지 생각해보자**

const identity = x => x;
identity(1);
identity(foo); 
identity(foo)();

** 결과 **

identity(1); // 1
identity(foo); // ƒ foo() {
  return 'bar';
  }
identity(foo)(); // 'bar'

identity(foo)가 함수를 return한 부분이 중요하다. identity(foo)()는 return한 함수를 실행시킨 결과를 반환했다.

3) 참조 평등(Referential equality)

참조 평등은 두 객체에 대한 포인터가 동일하다는 것을 의미한다. ** 결과를 예상해보자**

const anotherFoo = () => 'bar';
function sameFoo() {
  return 'bar';
}
const fooReference = foo;

'hello' === 'hello';
greeting === otherGreeting;

foo === foo;
foo === otherFoo;
foo === anotherFoo;
foo === sameFoo;
foo === fooReference;

결과

'hello' === 'hello'; // true
greeting === otherGreeting; //true

foo === foo; // true
foo === otherFoo; // false
foo === anotherFoo; // false
foo === sameFoo; // false
foo === fooReference; //true

여기서 눈 여겨봐야 하는 부분은 greeting === otherGreeting; //true와 foo === sameFoo; // false의 결과가 전혀 다른 것이다. foo와 smaeFoo는 실제로 같지 않다. 즉, *포인터의 위치가 같지 않다. *

3. useCallback과 useMemo

자, 위의 사전 지식을 열심히 습득했다면 이제 useCallback과 useMemo의 차이를 짐작할 수 있다!!!! ** useCallback과 useMemo가 무엇을 반환하는지 생각해보자**

useCallback(fn, deps)
useMemo(fn, deps)

결과 useCallback은 호출되지 않은 함수를 반환 useMemo호출한 함수의 결과를 반환

identity(foo);와 identity(foo)();의 결과 차이를 다시 생각해보자!!

useCallback과 useMemo의 사용

function foo() {
  return 'bar';
}

CONST memoizedCallback = useCallback( foo, []);
CONST memoizedResult = useMemo( foo, []);

** 위를 바탕으로 다음의 실행 결과를 예상해보자**

memoizedCallback;
memoizedResult;
memoizedCallback();
memoizedResult();

결과

memoizedCallback; 
// f foo() {
  return 'bar';
}
memoizedResult; // 'bar'
memoizedCallback(); // 'bar'
memoizedResult(); // TypeError

4. 실제 리액트에서

리액트에서 useCallback과 useMemo가 사용되는 모습

function MyComponent({foo, initial}) {
  const memoizedCallback = useCallback(() => {
    someFunc(foo, bar);
  }, [foo, bar]);

  const memoizedResult = useMemo(() => someOtherFunc(foo, bar), [foo, bar]);
  // 등등
}

• useCallback은 deps를 사용하는 함수를 호출하는 inline callback을 사용한다.
• useMemo은 일부 함수를 호출하고 그 결과를 반환하는 "create function"을 사용한다.

  1) 잘 못 사용된 useCallback!!

• • 왜 다음은 잘 못 되었을까?**

    function sum(a, b) {
    console.log('sum() ran');
    return a + b;
    }
    

function App() { const [val1, setVal1] = useState(0); const [val2, setVal2] = useState(0); const [name, setName] = useState('Jim');

const result = useCallback(sum(val1, val2), [val1, val2]);

return (

**힌트 : ```useCallback```은 함수를 반환하지 값을 반환하지 않는다**

**답**
 : ```useCallback```는 값의 메모이제이션에 사용할 수 없다. 즉. ```useCallback(fn(), [deps])```로는 사용 불가

 ## 2) 앗, 나의 실수는?

import React, { useEffect, useState } from 'react'; import ListItem from '@material-ui/core/ListItem'; import ListItemText from '@material-ui/core/ListItemText';

function User({ userId }) { const [user, setUser] = useState({ name: '', email: '' });

const fetchUser = async () => { const res = await fetch( https://jsonplaceholder.typicode.com/users/${userId} ); const newUser = await res.json(); setUser(newUser); };

useEffect(() => { fetchUser(); }, []); return ( ); }

export default User;

 해당 컴포넌트를 실행시킨다면 Infinity Loop를 확인 할 수 있다. 
 **클로저** 때문...!

const fetchUser = async () => { const res = await fetch( https://jsonplaceholder.typicode.com/users/${userId} ); const newUser = await res.json(); setUser(newUser); // 🔴 setState triggers re-render };

useEffect(() => { fetchUser(); }, [fetchUser]); // fetchUser is a new function on every render

 ```setState```가 계속 랜더링이 되도록 만든다. 
 그럼 해결책은 어떤 것이 있을까?

 ### (1) 클로저 해결 
 : ```useEffect```내로 ```fetchUser``` 함수를 이동시켜 클로저 문제를 해결

// 1. Way to solve the infinite loop useEffect(() => { const fetchUser = async () => { const res = await fetch( https://jsonplaceholder.typicode.com/users/${userId} ); const newUser = await res.json(); setUser(newUser); // Triggers re-render, but ... };

fetchUser(); }, [userId]); // ✅ ... userId stays the same.

 ### (2) useCallback 사용!
 : ```userId```가 바뀌면 ```fetchUser```가 호출된다.  

// 2. Way to solve the infinite loop const fetchUser = useCallback(async () => { const res = await fetch( https://jsonplaceholder.typicode.com/users/${userId} ); const newUser = await res.json(); setUser(newUser); }, [userId]);

useEffect(() => { fetchUser(); }, [fetchUser]); // ✅ fetchUser stays the same between renders

 ## 3) 비효율적인 함수를 어떻게 바꿀까?
 기능에는 문제가 없지만 랜더링 될 때마다 실행되는 함수... 어떻게 할까?

// Some FP magic 🧙🏼‍♂️ const filter = (f, arr) => arr.filter(f); const prop = key => obj => obj[key]; const getName = prop('name'); const strIncludes = query => str => str.includes(query); const toLower = str => str.toLowerCase(); const pipe = (...fns) => x => fns.reduce((y, f) => f(y), x); const nameIncludes = query => pipe( getName, toLower, strIncludes(toLower(query)) );

function UserList({ query, users }) { // 🔴 Recalculated on every render const filteredUsers = filter(nameIncludes(query), users); // ... }

 ### 해결!
 : ```query```와 ```users```가 변경 되지 않으면 ```filteredUser``` 호출 없이 기존 값을 가져오도록!

function UserList({query, users}) { // ✅ Recalculated when query or users change const filteredUsesr = useMemo( () => filter(nameIncludes(query), users), [query, users] ); };

<html>
  <head>
      <meta property="og-title" content="뿌린만큼 거두리라 다운받기">
      <meta property="og-description" content="뿌린만큼 거두리라 <br> 가장쉽고 (중략)">
      <meta property="og-image" content="http://lh3.googleusercontent.com/-v-...">
  </head>
</html>

• 구체적 작동 원리
  1. 사용자가 링크를 입력창에 입력
  2. 페이스북, 네이버 블로그, 카카오톡 입력창의 문자열이 'link'임을 파악(보통 정규표현식으로 해당 문자열이 링크라는 것을 알아냄)
  3. 'link'라는 것이 파악되면 페이스북, 네이버 블로그, 카카오톡의 크롤러는 미리 그 웹 사이트를 방문해 HTML head의 오픈 그래프(Open Graph) 메타 데이터 긁어옴
  4. 이 중 og:title, og:description, og:image가 각각 제목, 설명 ,이미지 정보를 나타낸다.
  5. 그 정보를 바탕으로 미리보기 화면을 생성한다.
• but, 캐시 저장 부분이 있다면 정보를 변경하더라도 캐시로 저장된 부분으로 인해 변경전 정보가 나올 수 있다.

정말 오랜만에 프로그래머스를 풀었다. 마지막 블로그 이후 띄엄띄엄하다가 어느순간 안 풀었는데 계속 신경이 쓰여서 오늘!!! 완전 각 잡고 다시 풀어보았다.

완주하지 못 한 선수

문제 설명 수많은 마라톤 선수들이 마라톤에 참여하였습니다. 단 한 명의 선수를 제외하고는 모든 선수가 마라톤을 완주하였습니다.

마라톤에 참여한 선수들의 이름이 담긴 배열 participant와 완주한 선수들의 이름이 담긴 배열 completion이 주어질 때, 완주하지 못한 선수의 이름을 return 하도록 solution 함수를 작성해주세요.

제한사항

• 마라톤 경기에 참여한 선수의 수는 1명 이상 100,000명 이하입니다.
• completion의 길이는 participant의 길이보다 1 작습니다.
• 참가자의 이름은 1개 이상 20개 이하의 알파벳 소문자로 이루어져 있습니다.
• 참가자 중에는 동명이인이 있을 수 있습니다.

입출력 예시는 밑의 링크에서 확인!!

출처: https://programmers.co.kr/learn/courses/30/lessons/42576

첫번째 작성

function solution(participant, completion) {
  const participants = {};

  for(let key of participant) {
    if(!participants[key]) {
      participants[key] = 1;
    } else if(participants[key]) {
      participants[key] += 1
    }
  };

  for(let key of completion) {
    if(participants[key]) {
      participants[key] -= 1;
    }
  }

  for(let person in participants) {
    if(participants[person] > 0) {
      return person;
    }
  }
};

생각의 흐름으로 작성한 풀이이다. 문제만 읽고 어떻게 풀어야할지 전혀 감을 못 잡다가 프로그래머스에 해시 키워드로 문제가 되어 있어서 Object[key] = value만 생각하고 풀었다. 문제는 해결했지만 다른 사람들 풀이를 보니 유난히 문제 풀이 방법이 길어보이고 특히 for...in이 반복문으로 쓰는 것을 권장하지 않는다는 댓글을 보고 다시 작성해보았다.

두번째 작성

function solution(participant, completion) {
   participant.sort()
   completion.sort()

  for(let i = 0; i < participant.length; i++) {
    if(participant[i] !== completion[i]) {
      return participant.slice(i, i+1)[0]
    }
  }
};

아주 많이 줄어들었다. 일단 sort()를 쓰는 것은 옛날에 이 문제를 봤을 때 생각하고 지나갔었는데 이번에 다른 사람 풀이를 보면서 기억이 나서 썼다. 그리고 for...in문을 사용하지 않았다! 댓글대로 for...in문을 사용하지 않으니 70ms -> 50ms로 속도가 줄었다. 하지만 정렬된 참가자와 완주자의 각 위치를 비교해서 완주하지 못 한 사람만 잘라내다 보니 결과가 배열로 나왔다. 이렇게 ['leo']!! 하지만 문제에서 요구한 결과 타입은 string으로 한 명만 결과로 도출되도록 되어있었다. 그래서 index [0]을 마지막에 적어뒀지만 뭔가 하드코딩같아보여서 별로이다.

다른 사람 풀이

function solution(participant, completion) {
    participant.sort();
    completion.sort();

    for(let i in participant) {
        if(completion.includes(participant[i]) == false) 
        return participant[i];

        completion.splice(completion.indexOf(participant[i]), 1);
    };
};

다른 분 풀이에서 주석처리한 부분만을 가져왔다. 왜냐하면 그 분이 주석처리 하지 않은 방법에는 for...in문이 사용되었기 때문이다. 나는 slice를 사용했지만 여기에는 splice가 사용되었다. 차이는 새 배열을 반환하느냐 여부이다. 그리고 이번에 splice가 속도가 느린 메서드라는 사실을 알았다. 유일하게 시간초과로 통과하지 못 했는데 제출 당시와 현재의 프로그래머스가 다르기 때문이 아닐까 싶다. 앞으로 가급적이면 slice를 쓰는 방향이 좋다는 것을 알았다.

Generator란?

비동기 작업을 동기적으로 표현하기 위한 방법 중 하나이다. 그 외 Promise, async/await가 있다.

1. 제너레이터는 어떻게 작성할까?

• function*과 같이 *를 function 뒤에 붙이면 제너레이터가 된다.
• 제너레이터 내부에 yield를 입력하면 제너레이터를 중지 및 재개 할 수 있다.
• next를 통해 제너레이터를 실행할 수 있다.

  function* sayHello() {
  console.log('제너레이터 시작')
  yield '안녕';
  console.log('첫번째 yield의 비동기 작업 끝낸 후 실행');
  yield '나는 Winney야'
  console.log('두번째 yield의 비동기 작업 끝낸 후 실행');
  yield '앞으로 잘 지내자'
  console.log('제너레이터 끝');
  };
  

const gen = sayHello();

gen.next(); // 1번 gen.next(); // 2번 gen.next(); // 3번 gen.next(); // 4번

# 2. 제너레이터의 실행은 어떻게 될까?
작성 방법을 알았으니 제너레이터가 어떻게 실행되는지 파악해야 할 차례이다. 
다음은 위의 예시를 실행한 결과이다.

// 1번 gen.next() 실행 '제너레이터 시작' { value: '안녕', done: false }

// 2번 gen.next() 실행 '첫번째 yield의 비동기 작업(안녕) 끝낸 후 실행' { value: '나는 Winney야', done: false }

// 3번 gen.next() 실행 '두번째 yield의 비동기 작업(나는 Winney야) 끝낸 후 실행' { value: '앞으로 잘 지내자', done: false }

// 4번 gen.next() 실행 '제너레이터 끝' { value: undefined, done: true }

여기서 중요한 부분은 ```next```를 이용해서 제너레이터를 작성했을 때 해당 제너레이터의 실행은 **```yield```작성한 부분에서 멈춘다**는 것이다. 

이후 다시 ```next```로 제너레이터를 실행했을 때 이전 ```yield```의 다음 줄에서부터 실행되어 그 다음 ```yield``에서 제너레이터가 멈추는 것은 반복한다는 것이다. 

즉, 위에서 말한 **```yield```를 입력하면 제너레이터를 중지 및 재개 할 수 있다.**는 의미의 ```yield```는 코드가 어딘가에서 멈춰서 비동기작업을 하고 해당 작업이 끝나면 다시 제너레이터가 실행 될 수 있게 하는 키워드라는 의미이다. 

그리고 위의 실행 결과를 통해 ```yield```는 객체형태로 ```value```와 ```done```을 반환하는 것을 알 수 있다. 

- ```value``` : ```yield```실행 결과의 반환 값
- ```done```: 제너레이터가 완전히 종료되었는지를 확인하는 값

때문에 4번째 ```gen.next()```의 ```yield``` 반환값을 확인하면 ```{ value: undefined, done: true }```를 확인 할 수 있다. 

이전 3번째 ```yield```가 마지막으로 실행되며 멈춘 다음 줄에서 4번째 ```gen.next()```가 실행되므로 ``` console.log('제너레이터 끝');```가 실행된 후 제너레이터가 끝난다. 
그렇기에 ```yield```가 없어서 반환값이 없으므로 ```value```는 ```undefined```가 나오고 제너레이터는 완전히 종료되었으므로 ```done```은 ```true```가 된다. 

# 3. 제너레이터로 어떤 것들을 표현 할 수 있을까?
제너레이터는 기본적으로 비동기 작업을 동기적으로 표현하므로서 가독성있게 표현하기 위한 것이다. (하지만 난 아무리 봐도 동기적으로 보인다... 물론 비동기 작업이 있다는 것을 알지만.. 😂)
## 제너레이터로 표현 할 수 있는 것
- API 호출 : 대표적인 비동기 작업!
- 자연수 표현하기
: 개인적으로 자연수 표현한 제너레이터를 보고 나도 모르게 내가 제너레이터를 함수처럼 생각하고 있었던 문제를 알 수있었다!

function* countNaturalNum() { let num = 0; while(true) { num += 1 yield num; } }

const gen = countNaturalNum() gen.next(); // { value: 1, done: false } gen.next(); // { value: 2, done: false } gen.next(); // { value: 3, done: false } gen.next(); // { value: 4, done: false }

만약에 함수였다면 무한루프를 돌았을 것이지만 제너레이터를 사용하면서 자연수를 표현할 수 있게 되었다. 

# 4. next에 인자를 넣으면 어떻게 될까?
>❗ **예시와 결과가 나오는데 예시만 보고 꼭 결과를 예측해볼 것**
- ```next```의 문법 : ```gen.next(value)```
- ```next```에는 매개변수가 있고 ```value```는 제너레이터에 전달된다. 

그리고 이미 배웠다시피 ```next```는 ```value```와 ```done``` 프로퍼티를 가진 객체를 반환한다.

## 1번 예시

function* getArg() { while(true) { let value = yield null; console.log(value); } }

const gen = getArg() gen.next(1); // 1번 gen.next(2); // 2번

## 1번 예시의 결과는 어떻게 나올까?

// 1번 { value: null, done: false }

// 2번 2 { value: null, done: false }

- 1번의 경우 : ```yield null```에서 멈추었기 때문에 ```yield```의 결과인 ```null```이 ```value: null```로 나타났다. 
- 2번의 경우 : 첫번째 ```yield``` 다음 줄부터 실행되기 때문에 ```console.log(value)```가 실행된다. 당연히 ```next(2)```에서 ```2```가 인자로 들어갔기 때문에 ```2```가 출력되고 while반복문이기에 다시 돌아가서 ```yield null```이 실행되어 ```value: null```가 나타난다. 

## 2번 예시

function* getArg() { returnedYield = yield 'foo'; yield returnedYield; }

const gen = getArg() gen.next(1); // 1번 gen.next(2); // 2번

## 2번 예시의 결과는 어떻게 나올까?

// 1번 { value: 'foo', done: false }

// 2번 { value: 2, done: false }

``` 제너레이터를 익히며 제일 어려웠던 부분이다!!

💥 중요 분명 gen.next(1)에서 1을 전달했는데 왜 value는 'foo'로 나올까? returnedYield는 어디로 갔나?

• mdn yield 문법 : [rv] = yield [expression]; 여기서 중요한 부분은 [expression]이다. 우리가 알아야 할 것은 next(value)에서 저 value 매개변수가 yield에게 전달되고 그 자리가 [expression] 자리라는 것이다. (yield오른쪽) 때문에 gen.next(1);를 통해서 1을 yield 'foo'에 전달하므로서 yield 1되었다.
• 하지만 yield 1이 returnedYield에 전달되는 것은 다음 yield가 실행될 때이다. * 그렇기에 1번 결과에서 우리는 value: 'foo'를 확인 할 수 있고 2번결과에서는 이미 next(2)를 통해 yield가 2를 value로 가진 상황에서 returnedYield를 반환하게 되므로 { value: 2, done: false }과 같은 결과가 나온 것이다.

참조 StackOverFlow : https://stackoverflow.com/questions/37354461/how-does-generator-next-processes-its-parameter

개인적으로 next에 인자를 전달한 값을 예측하는게 제일 어려운 부분이었다. iterator와 iterable에 관해서도 작성하고 싶지만 다음에 전반적으로 다루어 보도록 하고 제너레이터에 관한 내용을 마무리한다,

유니온 타입(Union Type)

: 복수의 타입을 쓸 수 있게 한다. JS의 OR 연산자의 역할과 같다. (||)

let address: string | number;
function writeTitle(title : string | number) {
  console.log(title);
};

writeTitle('Winney Log');
writeTitle(100);

6. 유니온 타입 대신 any를 쓸 수도 있지 않을까?

: 유니온 타입을 사용하면 타입 가드가 되어서 해당 타입을 추론해주고 이해 맞는 API를 자동완성 해주기 때문에 에러발생을 줄일 수 있다!!

function writeTitle(title: string | number) {
  // if문을 통해 타입 가드
  if(typeof title === 'string') {
    title.toUpperCase() // 문자열 API 자동완성
  }
  if(typeof title === 'number') {
    title.toString() // 숫자 API 자동완성
  }
  throw new TypeError('Title must be string or number');
}

7. 유니온 타입이 | 라면 &도 있나?

인터섹션 타입(Intersection Type)

: 여러 타입을 모두 만족하는 하나의 타입. & 사용.

interface Person {
  name: string;
  age: number;
}

interface Developer {
  name: string;
  skill: string;
}

function askSomeone(someone: Person & Developer) {
  console.log(someone.name); 
  console.log(someone.age);
  console.log(someone.skill);
};

const whoAmI = {
  name: 'winney',
  age: 10,
  skill: 'typescript'
};

askSomeone(whoAmI); // 정상
askSomeone({name:'winney', age:10, skill:'typescript'}); // 정상

8. 유니온 타입과 인터섹션 타입을 쓸 때 꼭 알아야 하는 건 뭐가 있을까?

: 각각의 타입을 typescript가 어떻게 추론하는지 알아야한다!!

유니온 타입과 인터섹션 타입의 차이

interface Person {
  name: string;
  age: number;
}

interface Developer {
  name: string;
  skill: string;
}

function askSomeone1(someone: Person | Developer) {
  console.log(someone.name); 
  console.log(someone.age);  // 에러
  console.log(someone.skill); // 에러
};

function askSomeone2(someone: Person & Developer) {
  console.log(someone.name); 
  console.log(someone.age);
  console.log(someone.skill);
};

❗ 에러가 난다는 것 === typescript가 API 자동완성을 안 해준다는 것 => typescript가 타입 추론을 못 한다.

askSomeone1과 askSomeone2의 차이에서 알 수 있는 것

• 유니온 타입은 공통된 property에 대해서만 type 보장을 한다. => Person과 Developer의 공통 property는 name이기 때문에 age과 skill은 에러
• 인터섹션 타입은 모든 property를 보장한다.

9. 유니온 타입에서 공통된 속성 외에 사용하고 싶은 속성은 어떻게 적용할까?

: 타입 가드 사용!!

// 타입 가드
function isDeveloper(someone: Person | Developer): someone is Developer{
  return (someone as Developer).skill !== undefined;
}

function askSomeone(someone: Person | Developer) {
  console.log(someone.name);
  if(isDeveloper(someone)) {
    console.log(someone.skill); // 타입이 Deeveloper이면 skill 사용가능
  } else {
    console.log(someone.age) // 타입이 Person이면 age 사용가능
  }
};

askSomeone({name:'winney', age: 10});
askSomeone({name:'winney', skill:'typescript'})

타입 가드를 사용해서 askSomeone 실행 시 에러없이 사용가능하다. askSomeone실행 시 각 타입에 맞는 값들을 넣으면 알아서 타입에 맞게 실행된다.

더해서

askSomeone({name:'winney', age:10, skill:'typescript'});

당연하지만 의 예시를 실행 할 시 name과 skill만 console에 출력된다.

🌈 최근 타입스크립트를 익히고 있다. 과거 프로젝트를 하며 타입 때문에 고생했던 적이 있어서 타입을 지정해준다는 것만으로도 굉장한 매력을 느끼고 있고 개인적으로 JS보다 재미있다. 물론 처음 배우는 거라 그럴 수도 있지만 typescript를 재밌다고 느끼는게 중요하지 않을까?! 하나씩 정리해보고자 한다.

1. 왜 타입스크립트를 쓸까?

제일 중요한 부분이라고 생각한다. 왜 쓰는가?

1. 정적 타입 지원으로 컴파일 단계에서 오류를 확인 할 수 있다.
2. IDE와 같은 도구의 지원을 받을 수 있다.
3. interface, generic을 통해 OOP 지원을 받을 수 있다.
4. ESNext를 지원한다.

2. 어떤 타입들이 있을까?

먼저 기본타입만 확인해보자.

• string : let animal: string = 'dog';
• number : let ten: number = 10;
• array : let fruit: Array<string> = ['banana', 'apple']; : let fruit: string[] = ['banana', 'apple'];
• tuple : let address: [string, number] = ['seoul', 20]
• object :

  let person: {name: string, age:number} = {
    name: 'winney', 
    age: 10,
    };

• boolean : let open: boolean = true;

추가적인 타입은 나중에 작성할 예정!

3. 함수는 어떻게 타입을 지정할까?

1) 인자와 반환값 모두 지정

let sum = (a: number, b: number) : number => {
    return a + b;
}

반드시 인자가 2개 있어야한다.

2) Optional parameter

let sum = (a: number, b?: number) : number => {
    return a + b;
}

인자 뒤에 ?를 붙여서 인자가 없어도 에러가 나지 않게 할 수 있다. ❗ optional parameter는 반드시 뒤에 위치해 있어야 한다. 다음과 같은 경우 ts에서 인식하지 못 한다.

let sum = (a?: number, b: number) : number => {
    return a + b;
}

4. 객체 property 지정을 더 현명하게 할 수 없을까?

• interface를 이용하면 객체 property를 여기저기 중복없이 지정할 수 있다.

  interface Person {
    name: string;
    age: number;
  }
  

let winney: Person = { name: 'winney', age: 10, }

let printUser = (user: Person) => { console.log(user) }

interface 사용으로 다양한 곳에 객체의 타입을 편하게 지정 할 수 있다.

interface Developer extends Person { skill: string }

let winney: Developer = { name: 'winney', age: 10, skill: 'ts' }

- interface는 확장이 가능하다 => OOP

추가로 타입 별칭이라는 부분이 있다. 

type Person = { name: string; age: number; }

``` 형태는 interface와 비슷하다. 하지만 interface와 달리 확장이 되지 않고 preview가 interface와는 다르게 보인다.

대부분의 경우 interface를 많이 사용한다. 하지만 어떤 걸 사용하든 일괄적으로 사용하도록 해야한다.

출처

• 타입스크립트-입문 강의
• http://typescriptlang.org/

1-1. 입력된 수가 짝수라면 2로 나눕니다. 1-2. 입력된 수가 홀수라면 3을 곱하고 1을 더합니다. 2. 결과로 나온 수에 같은 작업을 1이 될 때까지 반복합니다.

예를 들어, 입력된 수가 6이라면 6→3→10→5→16→8→4→2→1 이 되어 총 8번 만에 1이 됩니다. 위 작업을 몇 번이나 반복해야하는지 반환하는 함수, solution을 완성해 주세요. 단, 작업을 500번을 반복해도 1이 되지 않는다면 –1을 반환해 주세요.

• 입력된 수, num은 1 이상 8000000 미만인 정수입니다.
• 입출력 예시 : n => result 6 => 8 16 => 4 626331 => -1 (508회 나옴)

작성

function solution(num) {
  let count = 0;
  if(num === 1) return count;

  while(num !== 1) {
    if(num % 2 === 0) {
      count++
      num=num /2
      if(num === 1) return count;
    } else if(num % 2 !== 0) {
      count++
      num = num*3+1
      if(num===1) return count;
    }
  if(count >= 500)return -1
  }  
}

반복을 몇 번 하게 될지 모르므로 while문을 사용했다. 처음에 조건으로 while(num===1) 이라고 작성하는 바람에 계속 실행이 되지 않았는데 나중에서야 알게되어 수정했다. 그리고 if(num === 1) return count;이 부분도 어디에 추가해야할지 헤매다가 같이 문제푸는 분의 도움을 받아 추가되었다. 여전히 한 줄 한 줄 뜯어보는 부분이 부족하다고 느껴진다.

다른 사람 풀이

function solution(num) {
  let count = 0;
  while(num !== 1 && count <500) {
    num % 2 === 0 ? num = num/2 : num = num *3 +1;
    count++
  }
  return num === 1 ? count : -1;
}

가장 마음에 들었던 풀이이다. 풀이 과정이 짧은 분들은 더 있었지만 개인적으로 가독성을 제일 우선으로 코드를 작성해야한다고 생각하고 그런 면에서 짧다고 가독성이 좋다고 생각하지는 않기 때문에 제일 마음에 들었다.

2016년 1월 1일은 금요일입니다. 2016년 a월 b일은 무슨 요일일까요? 두 수 a ,b를 입력받아 2016년 a월 b일이 무슨 요일인지 리턴하는 함수, solution을 완성하세요. 요일의 이름은 일요일부터 토요일까지 각각 SUN,MON,TUE,WED,THU,FRI,SAT

입니다. 예를 들어 a=5, b=24라면 5월 24일은 화요일이므로 문자열 TUE를 반환하세요.

• 2016년은 윤년입니다.
• 2016년 a월 b일은 실제로 있는 날입니다. (13월 26일이나 2월 45일같은 날짜는 주어지지 않습니다)
• 입출력 예시 : a, b => return : 5, 24 => TUE

작성 코드

function solution(a, b) {
    var answer = '';
  const days = ['FRI','SAT','SUN','MON','TUE','WED','THU'];
  const monthDates=[31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31];


  let date = 0;
  for(let i = 0; i < a-1; i++) {
    date += monthDates[i];
  }

  let number = (b + date) % 7;
  if(number === 0) {
    return days[6];
  }
    return days[number-1];
}

처음 문제를 봤을 때 2월 29일, 30일, 31일로 월을 나눠서 생각했다가 7, 8월에 연속으로 31일이 나오기 때문에 처음 생각 포기했다.

그 후로 아무 생각이 안 나다가 그냥 모든 날짜를 더해서 나머지로 요일을 확인하면 되지 않을까? 하고 작성하게 된 코드이다. 처음 작성 했을 때는 if문이 없었기 때문에 나머지가 0일 경우 days의 맨 마지막에 있는 'THU'를 반환하지 못 했기에 if를 추가 했다.

다른 분들 풀이를 보니 new Date를 사용한 풀이가 있었댜. 생각지도 못 한 방법이라 굉장히 신선했다.

점심시간에 도둑이 들어, 일부 학생이 체육복을 도난당했습니다. 다행히 여벌 체육복이 있는 학생이 이들에게 체육복을 빌려주려 합니다. 학생들의 번호는 체격 순으로 매겨져 있어, 바로 앞번호의 학생이나 바로 뒷번호의 학생에게만 체육복을 빌려줄 수 있습니다. 예를 들어, 4번 학생은 3번 학생이나 5번 학생에게만 체육복을 빌려줄 수 있습니다. 체육복이 없으면 수업을 들을 수 없기 때문에 체육복을 적절히 빌려 최대한 많은 학생이 체육수업을 들어야 합니다.

전체 학생의 수 n, 체육복을 도난당한 학생들의 번호가 담긴 배열 lost, 여벌의 체육복을 가져온 학생들의 번호가 담긴 배열 reserve가 매개변수로 주어질 때, 체육수업을 들을 수 있는 학생의 최댓값을 return 하도록 solution 함수를 작성해주세요.

• 전체 학생의 수는 2명 이상 30명 이하입니다.

• 체육복을 도난당한 학생의 수는 1명 이상 n명 이하이고 중복되는 번호는 없습니다.

• 여벌의 체육복을 가져온 학생의 수는 1명 이상 n명 이하이고 중복되는 번호는 없습니다.

• 여벌 체육복이 있는 학생만 다른 학생에게 체육복을 빌려줄 수 있습니다.

• 여벌 체육복을 가져온 학생이 체육복을 도난당했을 수 있습니다. 이때 이 학생은 체육복을 하나만 도난당했다고 가정하며, 남은 체육복이 하나이기에 다른 학생에게는 체육복을 빌려줄 수 없습니다.

• 입출력 예시 : n, lost, reserve => return (5, [2, 4], [1, 3, 5]) => 5 (5, [2, 4], [3]) => 4 (3, [3], [1]) => 2

수정 전

function solution(n, lost, reserve) {
  const students = new Array(n).fill(1)

  lost.forEach((student) => {
    students[student-1]--;
  })

  reserve.forEach((student) => {
    students[student-1]++;
  })

  for(let i =0; i < students.length;i++) {
    if(students[i] === 0 && students[i-1] === 2) {
       students[i-1]--
        students[i]++
    } else if (students[i] === 0 && students[i+1] === 2) {
      students[i+1]--
      students[i]++ 
    } 
  }

return students.filter(student => student >= 1).length
}

이 문제는 나에게 어려웠다. 문제에 따라 생각을 정리하고 코드를 작성하기 시작했는데 정리가 덜 된 건지 내가 잘 못 작성한 건지 코드가 생각처럼 작동 하지 않았다. (핑계를 대보자면 요즘 잠을 잘 못 자는데 오늘 2시간 자서 그렇다고 하고싶...)

처음에는 students배열을 새로 만들지 않고 lost, reserve를 각각 filter로 걸러서 비교하는 방법을 사용하려고 했는데 이 부분이 생각한 것처럼 작동 되지 않아서 헤매다가 그냥 새 배열을 만들어서 쓰는 방법으로 바꾸었다. 요즘 filter 쓰는 것에 살짝 꽂혀서 여기저기 쓰고 있는지라 반드시 filter를 쓰겠다는 집념이 return에 나타난다...ㅋㅋㅋㅋㅋㅋ

새 배열을 이용한 방법은 생각보다 쉽게 풀 수 있었다. 테스트 케이스 통과하는데서 버벅거리긴 했지만 +-를 거꾸로 작성해서 통과가 안 되었던 부분이라 역시 오타부터 봐야되구나 싶었다.

수정 후

function solution(n, lost, reserve) {
  const students = new Array(n).fill(1)

  lost.forEach((student) => {
    students[student-1]--;
  })

  reserve.forEach((student) => {
    students[student-1]++;
  })

  students.forEach((student, i) => {
      if(students[i] === 0 && students[i-1] === 2) {
       students[i-1]--
        students[i]++
    } else if (students[i] === 0 && students[i+1] === 2) {
      students[i+1]--
      students[i]++ 
    }
})

return students.filter(student => student >= 1).length
}

기존의 for문을 forEach로 바꾸었다. 전반적으로 보기 좋게 하고 싶기에 별로 만족스럽지는 않다.
게다가 naming... 진짜 너무 어려운 것같다. 다른 사람의 풀이를 볼 때마다 느끼지만 naming이 가독성에 어마어마한 영향을 끼친다는 걸 새삼 알게된다. 지금도 만족스러운 이름들을 아니지만 많이 써보면서 내 스타일을 찾아나가야겠다.

대문자와 소문자가 섞여있는 문자열 s가 주어집니다. s에 'p'의 개수와 'y'의 개수를 비교해 같으면 True, 다르면 False를 return 하는 solution를 완성하세요. 'p', 'y' 모두 하나도 없는 경우는 항상 True를 리턴합니다. 단, 개수를 비교할 때 대문자와 소문자는 구별하지 않습니다.

예를 들어 s가 pPoooyY면 true를 return하고 Pyy라면 false를 return합니다.

• 문자열 s의 길이 : 50 이하의 자연수
• 문자열 s는 알파벳으로만 이루어져 있습니다.
• 입출력 예시 : 'pPoooyY' => true 'Pyy' => false

  수정 전

  function solution(s){
    var answer = true;
    let pCount = 0;
    let yCount = 0;
    const sArr = s.toLowerCase().split('');
    for(let s of sArr) {
        if(s === 'p') {
            pCount++
        }else if(s === 'y'){
            yCount++
        }
    }
    if(pCount === 0 && yCount === 0) {
        return true;
    }else if(pCount === yCount) {
        return true
    }else {
        return false
    }
  }

  또 생각한 그대로 작성해나갔다. 통과는 되었는데 생각해보니 filter를 쓸 수 있지 않을까 해서 수정해보았다.

수정 후

function solution(s) {
  const lowerArr = s.toLowerCase().split('');
  const pArr = lowerArr.filter(p => p === 'p');
  const yArr = lowerArr.filter(y => y === 'y');
  return pArr.length === yArr.length ? true : false;
}

코드 길이가 절반은 줄었고 한 번에 알아보기도 쉬워졌다. 하지만 filter를 중복으로 쓰고 있다는 느낌이라 좀 아쉬운 느낌이다.

다른 사람 풀이 01

function numPY(s) {
  return s.match(/p/ig).length == s.match(/y/ig).length;
}

이 풀이를 보면서 match에 대해 알게되었다. 하지만 이 경우에는 'p'와 'y'가 없을 경우의 예외처리가 되지 않는 다는 댓글을 보았다. 생각해보니 p와 y가 없다면 배열이 만들어지지 않아져 null값이 나올 것이고 length를 구할 수 없다. 나는 if문을 이용해서 수정했지만 놀랍게도 아주 간단하게 예외처리를 한 풀이가 있어서 안 가져 올 수가 없었다.

다른 사람 풀이 02

function solution(s) {
  return match = s.match(/p/ig)?.length === s.match(/y/ig)?.length;
}

?를 추가해 예외처리를 끝냈다. 오... null === null라는 점을 이용한 풀이인데 전혀 생각도 못 했다. 역시 꾸준히 써보고 생각하는 연습이 필요한 것같다.

수포자 삼인방은 모의고사에 수학 문제를 전부 찍으려 합니다. 수포자는 1번 문제부터 마지막 문제까지 다음과 같이 찍습니다.

1번 수포자가 찍는 방식: 1, 2, 3, 4, 5, 1, 2, 3, 4, 5, ... 2번 수포자가 찍는 방식: 2, 1, 2, 3, 2, 4, 2, 5, 2, 1, 2, 3, 2, 4, 2, 5, ... 3번 수포자가 찍는 방식: 3, 3, 1, 1, 2, 2, 4, 4, 5, 5, 3, 3, 1, 1, 2, 2, 4, 4, 5, 5, ...

1번 문제부터 마지막 문제까지의 정답이 순서대로 들은 배열 answers가 주어졌을 때, 가장 많은 문제를 맞힌 사람이 누구인지 배열에 담아 return 하도록 solution 함수를 작성해주세요.

• 시험은 최대 10,000 문제로 구성되어있습니다.

• 문제의 정답은 1, 2, 3, 4, 5중 하나입니다.

• 가장 높은 점수를 받은 사람이 여럿일 경우, return하는 값을 오름차순 정렬해주세요.

• 입출력 예시 : [1,2,3,4,5] => [1], [1,3,2,4,2] => [1,2,3]

  function solution(answers) {
  const answer = [];
  const firstStudent = [1,2,3,4,5];
  const secondStudent = [2,1,2,3,2,4,2,5];
  const thirdStudent = [3,3,1,1,2,2,4,4,5,5];
  
  const firstStudentAnswerCount = answers.filter((answer, index) =>
    answer === firstStudent[index % firstStudent.length]).length
  const secondStudentAnswerCount = answers.filter((answer, index) => 
      answer === secondStudent[index % secondStudent.length]).length
  const thirdStudentAnswerCount = answers.filter((answer, index) => 
     answer === thirdStudent[index % thirdStudent.length]).length
  

const maxArr = [firstStudentAnswerCount,secondStudentAnswerCount,thirdStudentAnswerCount]

for(let i =0 ; i < maxArr.length; i++) { const max = Math.max (firstStudentAnswerCount,secondStudentAnswerCount,thirdStudentAnswerCount) if (maxArr[i] >= max) { answer.push(i+1) } }

return answer; }

```

1. 각 학생이 답을 찍는 패턴을 배열로 만든다.
2. 각 학생들이 맞춘 답의 개수를 찾는다. (filter 사용)
3. 학생들이 맞출 답의 개수를 배열에 담는다.(maxArr)
4. 맞춘 답 중 가장 큰 수를 찾는다. (max)
5. for문으로 가장 많이 맞춘 답의 개수(max)와 각 학생이 맞춘 답의 개수를 비교해 해당 학생의 번호(i+1)을 answer 배열에 넣는다.

이번에 가장 막혔던 부분은 answers의 길이가 학생의 답 패턴 배열보다 무조건 긴데 이걸 어떻게 answers 끝까지 비교할 것인가였다. 원래는 Math.ceil(answers.length/studentAnswer.length)를 해서 나온 값을 studentAnswer에 붙여서 for문을 할까라고 막연히 생각하다가 실현하기 힘들다는 생각이 들어서 포기했다.

계속 아이디어가 생각이 안 나서 결국 찾아봤는데 나머지 값을 구해서 반복적으로 answer를 비교하는 방법이 있었다. 역시 사람들이 똑똑하다...

그 이후로는 문제 풀이가 매끄럽게 흘러갔다.

마지막의 for문의 경우 지금은 학생 수가 3명이고 문제 자체도 3명으로 고정되어 있지만 학생이 늘어난다면 for문이 더 맞지 않을까해서 for문을 사용하게 되었다.

전체적으로 학생 수가 늘어날 경우를 감안해서 작성한 코드는 아니지만 만약에 학생 수도 늘어난다면 많은 부분을 고쳐야 할 것 같다. filter도 지금처럼 사용하기는 힘들겠고 maxArr도 지금처럼 직접 요소를 주는게 아닌 Array.push를 써야겠다.

프로그래머스 분류에 완전탐색이라고 되어 있던데 조만간 완전탐색에 대해 알아봐야겠다.