일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 백준
- BFS
- HTTP
- Algorithm
- TCP
- 자바스크립트
- 문자열
- 타입스크립트
- typescript
- 프로그래머스
- 가천대
- dfs
- type challenge
- HTTP 완벽 가이드
- 알고리즘
- 쉬운 문제
- Crawling
- socket
- Node.js
- ip
- dp
- Nestjs
- javascript
- 그래프
- 프로그래머스 레벨 2
- 레벨 1
- 수학
- 타입 챌린지
- 크롤링
- 소켓
- Today
- Total
목록프로그래밍 (478)
kakasoo
type SnakeToCamel = Join; 타입 파라미터 Target을 받는다. 이 타입 Target을 _ 문자를 기준으로 Split하면 문자열이 배열의 형태가 되는데, 이를 일단 P에 저장한다. 이제 이 문자열 배열 P를 mapped type을 이용하여 첫번째 문자를 제외한 나머지 문자열들은 첫글자만 대문자로 변경한다. 이렇게 만들어진 문자열 배열을 다시 하나의 문자열이 되게 Join한다. 타입 레벨에서 문자열 Join 구현하기 type ToString= T extends string ? T : never; type ToStringTuple= T extends string[] ? T : never; typ..
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년 후에도 다 못외우고 있을지도 모른다. 그런데 만약 모..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/ofZb5/btsmA1CYAja/983kAFIH5BCRNy9UbTdkkk/img.png)
모놀리식 지옥의 실상 모놀리식 아키텍처의 근본적인 한계는 성공한 어플리케이션 부터 생긴다. 더 큰 서비스, 더 많은 기능, 더 많은 개발자들은 애자일식 개발/배포도 불가능한 상황이 온다. 서비스는 너무 복잡해져서 어떤 개발자도 전체를 ‘완전히’ 이해하는 게 불가능해진다. 단일 코드베이스는 소통/조정에 오버헤드를 유발하고, 코드를 커밋한 후 반영되기까지 매우 긴 지연이 발생한다. 당연히 이런 큰 코드들은 IDE의 실행 속도도 늦추고 개발 속도를 계속 떨어드린다. 확장은 어렵고, 신뢰성이 떨어지며 ( 에러 발생 시 전체 서비스가 다운된다 ) 새로운 기술을 적용하기도 어렵다. 마이크로서비스 아키텍처 모놀리식의 단점을 느끼고 있다면 서비스가 성공적이었다는 것을 의미해도 될 거 같다. 만약 서비스가 비대해져서 더..