[정리] 그냥 저냥 #위클리뉴스 #63

⏰개발자들이 읽어 보면 좋을

서비스 가용성 확보에 필요한 Rate Limiting Algorithm에 대해 | Mimul Tech log

• 서비스 운영을 하다 보면, 이런 저런 상황이 많이 발생하면서 실제 사용자들이 제대로 서비스를 받지 못하게 될 수 있는데, 이럴때 속도 제한(Rate Limiting Algorithm). 음, 웹 서비스라고 가정하면, 요청 제한 알고리즘이라고 이해 하면 좋겠다. 요청 대비 처리량을 어떻게 잘 제한을 하면서 서비스 할 지에 대한 고민의 해답이라고 생각 한다. 이런 제한이 필요하다고? 생각할 수 있지만, 서비스가 커지면 필수적으로 고려해야 할 요소 중 하나이다. 그렇지 않으면, 장애 요소가 될 수 있다.

기술 부채도 자산인 이유

• 기술 부채가 정말 나쁜 것인가?에 대해 "그렇다"라고 쉽게 말할 수 없다. 오늘의 코드는 내일 모레 레거시가 된다. 고로, 내가 아무리 레거시 코드를 청산 한다고 해도, 청산 하는 속도만큼 레거시가 또 생겨나는 것이다. 결국, 기술 부채는 항상 있기 마련, 얼마나 기술 부채의 적정량을 유지 하느냐?가 관건 같다. 그래서 주기적인 시스템, 코드의 부채를 점진적으로 갚는 노력을 하는 방법이 좋다고 생각 한다. 그렇지만, 큰 규모에서는 그게 쉽진 않지만, 결국 관리자의 몫과 함께 코드 주인인 개발자의 노력이 필요하다. 팀 마다 부채 청산 룰을 정하는 것은 좋다고 생각 한다.

퇴사자를 대하는 태도

• 링크드인이라는 회사의 퇴사자를 대하는 태도에 대한 글인데, 굉장히 놀랍다. 사실 쉬운 일은 아닌데도 그러한 문화를 유지 하고 있다는게 대단하다는 생각을 했다. 국내 기업에도 이러한 문화가 도입 되면 좋겠다. 사실, 그럴려면 나부터 열린 마음으로 대하면 되는 거겠지? 🙏🏻

난생 처음으로 개발로 발표해보았다! (Feat. ip블로킹, activeX크롤링하기)

• 크롤링을 주력으로 하시는 분 같았는데, 총 2가지의 난제(ip block, active x)를 해결하면서 얻은 경험기 공유입니다. 10분정도의 라이트닝 발표이다 보니 굉장히 짧아서 아쉽긴 하지만, 다양한 방법으로 해결 하려는 노력을 엿볼 수 있습니다. (그런데, 공공기관의 경우, 정보 공개에 의한 법률로 제정이 되어 있을지라도, 악의적인 크롤링은 금물입니다. 일반 서비스도 마찬가지 :)

📺Java

What is Spring Boot ? | Examples Java Code Geeks - 2020

• 스프링 부트가 무엇인지? 사실 정확하게 딱딱 가리기가 어려운데, Spring Boot에 대해 잘 정리가 되어 있다.

📖JavaScript

Interviewing at Facebook - On-Site JavaScript Technical Interview Questions

• 페이스북의 온 사이트 인터뷰에서의 JavaScript 문제이다. 총 4문제이고, 쉬움, 중간 2개, 어려움으로 구분 되어 있다. 직접 풀어 보진 않았지만, 조만간 풀어 봐야겠다.

자바스크립트 성능 향상 방법

• 여러 가지 성능 향상 방법이 있는데, 그 중에서 객체를 캐싱 하는 방법은 유용하지만, 때로는 오동작의 위험이 있으니 조심 해야 하지 않을까? 하는 생각이 들었다. HTTP 프로토콜 캐시는 대부분 사용하는 곳이 많을 것 같고, 서비스 워커 혹은 스토어 데이터 캐싱 관련해서는 확인을 잘 해야 한다. 스토어 캐싱 전/후 (오류 상황)에 대한 테스팅을 잘 해야 하지 않을까? 생각 한다.

어떻게 하면 안전하게 함수를 합성할 수 있을까?

• 생각 보다 쉽게 읽을 수 있을만한 내용은 아니였다. 사실 함수형 프로그래밍에 관심을 많지만, 개념을 이해하기가 쉽진 않다. 카테고리 이론이나, 펑터나 모나드등 써 보면 헤어나올 수 없다는데, 단점은 그 코드를 보는 모두가 이해해야 한다는 단점이 있다. 내용을 모르면 제대로 알 수 없다. 그래서 실무에서는 솔직히 제한적으로 쓸 수 밖에 없지 않을까? 하고 생각 했다.

블랙박스 테스트 기법으로 테스트 케이스 설계하기

• 블랙박스 테스트에 대해 설명하며, 4가지의 블랙박스 테스트를 소개 하고 있다. 사실, 이렇게까지 테스트 코드를 짜는가? 생각 해보면, 나는 전혀 아니다. 그치만, 팀원 중에는 정말 꼼꼼하게 작성 하시는 분들이 있다. 동등 분할, 경계값 분석, 결정 테이블, 상태 전이 각각 알 수 있어서 좋았고, 여유가 된다면 나도 이런 방향으로 작성 하도록 노력 해야겠다. 역시 테스트 코드는 진짜 습관화를 해야 하는 게 맞을 것 같다.

🛠Tool

Building personal search infrastructure for your knowledge and code | beepb00p

• Emacs와 ripgrep을 이용해 컴퓨터 내의 검색 엔진을 만들어 보는 건데, 사실 따라 하다가 실패했다.

개발 생산성을 올려주는 VSCode의 소소(?)한 기능들

• VS Code를 요즘에는 WebStorm 보다 많이 사용하는데, 사실 WebStorm의 3-way diff merge 기능만 빼면, VS Code로 거의 코딩을 하고 있다. VS Code에는 좋은 기능들이 숨겨져 있는데, 이 글을 보면서 내가 안 쓰던 기능을 익힐 수 있어서 좋았다.

💡일반적인

최고 수준의 기획자는 어떻게 되는가

• 나이별로 잘 정리 되어 있으나, 가장 중요한 것은 내가 기획 하려는 것의 본질을 명확하게 그리고 있는가? 아닐까? 목적 없이 기획 하는 경우가 많다.

IT 프로젝트가 처음이라면 꼭 알아둬야 할 5가지 툴

• 생소한 툴들이 좀 있는데, 모바일 테스팅 툴 같은 경우는 솔직히 필수적인 솔루션이라고 생각 한다. 테스트 없이 사용자에게 언제까지 테스트를 맡길 것인가? 사용자의 이탈은 시작 하면 막기 어렵다.

잘 쉬는 것에 대하여

• 메마름의 시대 같기도 하다. 나조차도 일 하다가 팀원들과 말하다가 어? 모르던 툴인데? 모르던 라이브러리인데? 하는 생각이 들면, 불안해진다. 그런데, 작년까지는 그랬다가 요즘은 머리가 커져서 그런가. 내려 놓게 되었다. "모르면 오, 이런게 있구나 하고 알아 가면 된다."는 마인드가 장착 되기 시작 했다. 부지런히 쉬자. 그래야 부지런히 일 할 수 있다.