일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 쉬운 문제
- 프로그래머스
- type challenge
- socket
- 크롤링
- 문자열
- typescript
- Nestjs
- ip
- BFS
- Crawling
- 자바스크립트
- dp
- Algorithm
- 그래프
- 소켓
- 가천대
- TCP
- 백준
- 프로그래머스 레벨 2
- dfs
- HTTP 완벽 가이드
- 레벨 1
- 알고리즘
- 수학
- 타입스크립트
- 타입 챌린지
- Node.js
- HTTP
- javascript
- Today
- Total
목록전체 글 (499)
kakasoo
type FirstLetterCapitalize = Target extends `${infer F}${infer Rest}` ? `${Uppercase}${Rest}` : Target; 문자열의 첫 글자만을 대문자로 변경하는 타입이다.
type Split = Target extends `${infer F}${Separator}${infer Rest}` ? [F, ...Split] : Target extends "" ? [] : [Target]; Join과 반대로 문자열을 분리하는 타입. Target이 Separator를 기준으로 F와 Rest로 나뉠 수 있는 문자열일 경우 이 둘을 잘라 배열에 담는 타입이다. Join 타입은 아래 링크들에서 확인할 수 있다. https://kscodebase.tistory.com/682 타입 레벨에서 문자열 Join 구현하기 type ToString= T extends string ? T : never;..
https://kscodebase.tistory.com/682 타입 레벨에서 문자열 Join 구현하기 type ToString= T extends string ? T : never; type ToStringTuple= T extends string[] ? T : never; type Join = T extends [infer F, ...infer Rest] ? `${ToString}${Join}` : ''; 문자열로 이루어진 배열을 받아 Join하는 타입을 구현했다. type kscodebase.tistory.com Join의 다른 구현 방법 type Join = Target extends [infer..
대중 문화와 같이 더 많은 사람들이 좋아하는 문화가 있긴 하지만, 기본적으로 문화에는 상하가 없다. 내가 코인 노래방에 가는 것과 지인이 오페라에 가는 것 사이에 상하는 없고, 내가 이마트 저녁 할인 초밥을 먹는 것과 지인이 오마카세에 가는 것 사이에도 상하는 없다. 어떠한 문화든지 간에, 그 안의 행위와 대상에 따라 좋고 나쁨이 결정될 일은 없다. 즉, 내가 내 지인보다 인간으로서 부족한 사람이라고 단정지을 수는 없는 것이다. 하지만 이들 문화의 상하가 없다고 하더라도 그 문화를 누리는 사람들, 집단의 차이가 정녕 없는 것은 아니다. 인간성을 부정하지 않는 채로도 수 많은 차이를 읊을 수 있다. 말하자면 적나라한 일이지만, 경제적 소득과 지식의 양, 교양의 수준 등 많은 부분에서 특정 문화를 향유하는 ..
1 아비투스란 아비투스는 프랑스 철학자 부르디외가 처음 제시한 개념으로 사회문화적 환경에 의해 결정되는 제2의 본성, 즉 타인과 나를 구별 짓는 취향, 습관, 아우라를 일컫는다고 한다. 계층 및 사회적 지위의 결과이자 표현이기도 하지만 저자는 “아비투스는 결코 돌에 새겨지지 않았다”고 선언한다. 너무 어려운 말이지만, 우리는 이렇게 질문해볼 수 있을 것 같다. 저 사람은 급이 다르다고 말할 때의 그 급의 차이는 어떻게 아는 것인가? 우리나라 사람들은 흔히 끼리끼리 논다는 말을 많이 쓴다. 그 끼리끼리를 결정하는 것은 또 무엇인가? 저자는 이를 두고 아비투스라고 한다. 다행히 아비투스는 경제적 수준, 권력 등을 의미하는 게 아니다. 그보다는 아비투스는 사회, 문화적 수준에 가깝다. 따라서 내가 가진 것이 ..
또는, setTimeout은 call stack의 제어권을 빼앗는가? function b () { let i = 0; while(true){ console.log('in'); i++; if (i % 1000 === 0) { new Promise((res) => { setTimeout(() => { console.log('ok'); }, 3000); }) } } console.log('out'); } 이 함수에서 내부의 setTimeout이 있는 Promise는 동작하지 않는다. 호출 스택에 있을 b가 끝나지 않기 때문이다. setTimeout의 시간에 도달한다고 하더라도, 호출 스택이 비지 않으면 이벤트 루프는 이벤트 큐의 함수를 호출 스택으로 내보내지 않는다. 즉, setTimeout은 호출 스택의 최..
회사 내에 배포되어 있는 라이브러리를 보고 npm Pro 결제 없이도 private하게 라이브러리를 배포할 수 있는 걸 알았다. 배포할 패키지가 있는 레포지토리에서 package.json에 pubhlishConfig를 추가 하고, .npmrc 파일을 만들어서 아래와 같이 내용을 추가한다. // 배포하려는 라이브러리 쪽 package.json { "name": "@username/repositoryName", "publishConfig": { "registry": "https://npm.pkg.github.com" }, ... } # 배포하려는 라이브러리 쪽 .npmrc @username:registry=https://npm.pkg.github.com/ 이후에 패키지를 다운 받는 쪽에서도 .npmrc 파일..
외부 API ( 나의 경우 페이스북, 구글 등 ) 를 이용하는 경우, DB가 분산되어 있는 경우 ACID를 어떻게 보장할까? 첫 번째로 살펴본 것은 2PC ( Two-Phase Commit ) 인데, 예제 코드는 아래와 같다. 이 코드는 각각의 작업 단위를 Node로 정의하여 원자성을 보장해야 하는 것들을 Coordinator에게 전달한다. 2PC 프로토콜은 트랜잭션을 커밋할지 롤백할지 결정하기 위해 모든 Node의 투표 결과를 확인한다. interface Node { name: string; vote: boolean | null; prepare(): void; // commit할지, rollback할지 투표를 한다. commit(): void; rollback(): void; } class Coordi..
마이크로서비스 패턴이라는 책을 읽고, NestJS 코드로 다시 이해한다. NestJS에서 가장 많이 볼 수 있는 구조는 Controller - Service - Repository 로 이어지는 계층화된 아키텍처 (layered artchitecture)다. 이는 표현 계층, 비즈니스 로직 계층, 영속화 (persistence) 계층이라고 하는데, Controller는 사용자 인터페이스 또는 외부 API가 구현된 계층, Service는 비즈니스 로직이 구현된 계층, 영속화 계층은 DB 상호작용 로직이 구현된 계층이라는 뜻이다. 여기에는 한 가지 문제가 있다. 과연 어플리케이션에 동작을 의뢰하는 계층이 Controller 밖에 없는가? NestJS를 해봤다면 이미 정답을 할 텐데, 배치 시스템이나 소켓 통신..
콘웨이의 법칙에 대해서 읽었을 때 이게 무얼 의미하는 지 몰랐다. 콘웨이의 법칙 지인에게 MSA에 대해 설명하다가 이걸 왜 해야 하냐는 이야기를 들었다. API의 요청 수가 많아져서 서버가 죽는 속도가 서버의 증설 속도보다 빨라지는 시점에 서버는 차례대로 다운되고 결국 모든 서버가 닫히면서 서비스가 중단된다는 설명을 해줬다. 기술적으로는 그랬다. 그런데 불현듯 조직에 대한 생각이 들었다. 기술적인 부분 말고도, 조직 관리 측면에서도 MSA는 필연적인 것은 아닐까? 나는 지금 내 생황이 떠올랐다. 나는 새로운 회사로 이직한지 이제 일주일이 되었는데, 이 회사는 현재 100명이 넘는 사람이 있어서 사람들 얼굴과 이름을 외우는 것도 한 세월이다. 아마 1년 후에도 다 못외우고 있을지도 모른다. 그런데 만약 모..
모놀리식 지옥의 실상 모놀리식 아키텍처의 근본적인 한계는 성공한 어플리케이션 부터 생긴다. 더 큰 서비스, 더 많은 기능, 더 많은 개발자들은 애자일식 개발/배포도 불가능한 상황이 온다. 서비스는 너무 복잡해져서 어떤 개발자도 전체를 ‘완전히’ 이해하는 게 불가능해진다. 단일 코드베이스는 소통/조정에 오버헤드를 유발하고, 코드를 커밋한 후 반영되기까지 매우 긴 지연이 발생한다. 당연히 이런 큰 코드들은 IDE의 실행 속도도 늦추고 개발 속도를 계속 떨어드린다. 확장은 어렵고, 신뢰성이 떨어지며 ( 에러 발생 시 전체 서비스가 다운된다 ) 새로운 기술을 적용하기도 어렵다. 마이크로서비스 아키텍처 모놀리식의 단점을 느끼고 있다면 서비스가 성공적이었다는 것을 의미해도 될 거 같다. 만약 서비스가 비대해져서 더..
1 회사에서도 무언가 배우자. 회사에서 배움을 찾는 사람들한테 "직장은 배우러 가는 곳이 아닙니다." 라고 말하는 사람도 있지만, 내 생각엔 배우러 가는 게 맞다. 군대에 가서 삽질만 하더라도 뭔가 배울 게 있었는데 그건 뭘 하는지에 달린 게 아니라 생각을 하느냐 마느냐의 차이였던 것 같다. 어느 환경에서든 생각하기를 멈추질 않으면 배우는 게 있었다. 그러니깐 첫째로는 회사에서도 항상 무언가 배우려고 하자. 그게 개발이든, 아니든. 2 TIL 열심히 하자. 가끔 가다가 남들에게 자랑하고 싶은 게 있다면 TIL 말고 블로그 포스팅도 하자. 3-1 퇴근 후에도 공부하자. 원래 1년의 목표를 정하고 움직였지만, 생각해보니 1년이나 동일한 목표를 가지는 건 불가능했고, 그래서 하루 단위로만 목표를 세우자고 했지..