2022.01.04

한 일

• 면접...!
  • 털렸다!
• 스터디!

배운 것

• 객체에서 프로퍼티 key 존재 여부를 확인하는 방법(예를 들면 dictionary 만들 때)

1. dic.hasOwnProperty(key)
   • 자신의 프로퍼티들에서만 확인하기 때문에 이 방법으로 확인해서 없다고 판단하고 프로퍼티를 추가하면 의도치 않게 프로토타입의 프로퍼티를 오버라이드해 사용하지 못하게 될 수 있음!
   • 이걸 보완하기 위해 나온 것이 Object.hasOwn(obj, key)
     • 프로토타입 체인까지 탐색함. 아직 정식 스펙은 아니다!
2. key in dic
   • 프로토타입 체인을 순회하면서 전부 찾아본다! 프로토타입에 있어도 true반환
   • 해당 key의 value에 undefined 할당 되어 있어도 정상적으로 key 있다고 true 반환해줌! 안전하다
3. dic[key] !== undefined
   • 해당 key에 undefined 할당되어 있으면 key 있어도 false가 되어버림...!
     • 이걸 in 설명할 때 말해버렸다...! 아ㅋㅋ

Object.prototype.hasOwnProperty() - JavaScript | MDN (mozilla.org)

Object.prototype.hasOwnProperty() - JavaScript | MDN

Object.hasOwn() - JavaScript | MDN (mozilla.org)

Object.hasOwn() - JavaScript | MDN

in 연산자 - JavaScript | MDN (mozilla.org)

in 연산자 - JavaScript | MDN

• 화상회의나 라이브 방송 같은 서비스에서 왜 미디어 전송 WebRTC를 사용할까? WebSocket은 안돼?
  • 실시간 미디어 스트리밍은 실시간성이 중요함 즉 레이턴시가 적어야됨. 그리고 영상은 전송하는 데이터 크기가 크다...!
  • 때문에 전송속도도 빨라야 하고 지연이 적어야함
    • 지연이 크면 사용자가 답답함을 느낄 수 있음!
  • WebSocket은 TCP 기반으로 데이터를 전송함. TCP는 신뢰성이 높지만 높은 신뢰성을 보장하기 위해 유실 패킷을 재전송 하는 등의 작업이 필요해 레이턴시가 큼.
  • 반면 WebRTC는 미디어 데이터를 UDP를 이용해 전송해서 지연이 적고 빠름
    • 신뢰성이 떨어지지만 픽셀 몇개, 프레임 하나 정도 나가는게 실시간성 떨어지는 것 보다 낫다!
  • 그리고 WebRTC API가 미디어 다루기 더 좋게 되어있음! WebRTC 프로토콜 만든 목적이ㅎ
  • 채팅 메시지 같은 것도 WebRTC로 전송 가능 하지만 WebSocket 쓰는 이유는 채팅 메시지는 신뢰성이 중요해서 그렇겠지???
  • 공부를 더 깊게 해보자!

WebRTC – architecture & protocols – P's Blog (wordpress.com)

WebRTC – architecture & protocols

Why you should prefer UDP over TCP for your WebRTC sessions • BlogGeek.me

Why you should prefer UDP over TCP for your WebRTC sessions

 

느낀 점

• 최신 문법... at이나 top-level-await 말고 for await, for in, nullish coalescing operator, optional chaining 같은 평소에 그래도 써봤던 것들 얘기할껄 그랬다 ㅋㅋ
  • in 연산자는 프로젝트에서도 백준 문제 풀 때도 꽤 자주 썼었는데 바로 얘기 못하고 평소에 안쓰는 hasOwnProperty를 얘기해버렸다. 심지어 in 연산자에 대해 확실히 알지 못해 잘못된 얘기 해버렸다...ㅠㅠ
  • JS로 알고리즘 문제 풀기 전에는 문자열 순회할 때 for문 돌려서 index로 접근하면서 순회하면 되는데 괜히 spread 연산자로 펼쳐서 map, forEach로 순회했는데 이러면 순회하는데 2n이 걸린다... spread가 iterator를 순회하는데 n 그걸 다시 map, forEach 등으로 순회하는데 n 그래서 2n...
    • 데이터가 작으면 상관이 없겠지만(요즘 하드웨어 스펙이 워낙 좋으니 ㅎㅎ) 데이터가 크면 엄청 손해다...
    • 알고리즘 문제 풀 때 시간초과 or 효율성 실패 를 겪고 나서 깨닳았다. 이런적이 있었다고 면접 끝날 때 말했는데 괜히 말한 것 같음ㅎ
• 프로젝트에서 쓴 기술 왜 썼는지 기억 떠올려내서 명확하게 정리해야겠다.
  • 평소에 정리 안해놓으니 아 그냥 이래서 썼어요 밖에 안됨... 분명 이유가 있었는데ㅋㅋ;
• 어떤 기술이 어떤 이점이 있고 단점은 뭐가있는지 해결방안은 없는지, 대체 가능한 기술있는지! 잘 알아보자.
  • 대체 가능한 기술은 어떤 점이 더 좋은지... 또 왜 그런지 알아보자!
• 트렌디한 신기술, 최신 JS 문법 알아보는건 좋은데 공부 제대로 해서 잘 알고 쓰자...
• 아 불편하다~ 에서 끝나면 안된다! 개선할 방법을 찾아야한다! 특히 일이 아닌 학습하는 경우에는 시간이 촉박해도 꼭!
• 깊게 공부하기
  • 뭐든 얕게 공부하면 헷갈리기도 하고, 설명도 못한다... 깊게!
• 생각 잘 정리해서 말하기. 애매하게 말하지 말자ㅎ
• 면접 때 화이트보드 기능 잊지 말고 써먹자
• 카카오 엔터프라이즈 개발자 분들은 굉장히 멋진 분들이었다!
  • 굉장히 편한 분위기로 면접 진행해주셨다. 그런데 나는 기대에 부응하지 못함 ㅠㅠ
  • 부족한 점을 많이 알 수 있었다. 또 많이 배울 수 있었다! 정말 기회가 있다면 결과와 관계없이 다시한번 감사드리고 싶다.
• snowpack, vite, esbuild 같이 성능 좋은 빌드 도구들이 있다! 한번 써봐야지!