일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- Nestjs
- typescript
- HTTP
- 백준
- HTTP 완벽 가이드
- javascript
- 알고리즘
- 수학
- 프로그래머스
- dp
- type challenge
- Algorithm
- 소켓
- TCP
- 타입 챌린지
- dfs
- 타입스크립트
- 가천대
- Crawling
- 쉬운 문제
- 그래프
- 프로그래머스 레벨 2
- Node.js
- BFS
- 레벨 1
- ip
- 자바스크립트
- 문자열
- socket
- 크롤링
- Today
- Total
목록2022/09 (5)
kakasoo
수직확장과 수평확장 사람들은 확장성과 관련해 용량 확장(수직 확장), 규모 확장(수평 확장) 을 말한다. 수직 확장은 좀 더 강력한 장비로 이동하는 것이고, 수평 확장은 여러 기기들로 부하를 분산하는 것을 말한다. 서로 다른 기기로 부하를 나누기 때문에 수평 확장은 다시 비공유 아키텍처라고 부르기도 한다. 단일 장비에서 수행하는 시스템이 비교적 간단하기는 하지만, 고사양 장비는 매우 비싸 대개 규모 확장을 택한다. 적절한 장비 몇 대가 다량의 낮은 사양 가상 장비, 또는 몇 대의 높은 사양 가상 장비보다 저렴하고 효율적이다. 탄력적 (Elastic) 일부 시스템은 탄력적(elastic)이다. 즉, 부하 증가를 감지하면 컴퓨팅 자원을 자동으로 추가할 수 있다. 탄력적인 시스템은 부하를 예측할 수 없을 경우..
TypeORM에는 setFindOptions 라는 메서드가 있고, 이걸 활용하면 할 수 있는 일이 참 많습니다. 하지만 공식문서에는 이 메서드에 대한 소개가 전혀 없는데요, 이건 TypeORM이 반성해야 할 부분 같습니다. 이 메서드는, QueryBuilder가 가진 문제점을 부분적이나마 해소해줍니다. 코드를 통해 보겠습니다. QueryBuilder 사용법 const posts = await connection .createQueryBuilder(Post, "post") .where('post.author IS NULL') .orderBy("post.id", "ASC") .getMany() post를 조회할 때 우리는 where문과 order를 where, orderBy라는 메서드를 통해 해결할 수 있습..
원래 Repository에서 조인 대상에 대해 IsNull로 체크하는 것은 자잘한 버그들이 있었습니다. IsNull로 할 경우, 사용자가 기대하던 방식대로 동작하지 않았는데, 이게 버그인지 의도인지는 알 수 없었습니다. 그래서 이런 경우는, 차라리 쿼리빌더에서 InnerJoin을 하는 것이 낫다는 판단이었습니다. 어떤 식으로 동작할지 명확한 것이 차라리 낫다는 판단이었습니다. 그러고 나서 몇 달의 시간이 지나니 새로운 업데이트가 나왔습니다. 새 업데이트 내용을 보니, 기존의 코드가 의도된 게 아니라 버그였음을 확인할 수 있겠네요. 이 내용은 issue number #8890에 있는 코드를 그대로 옮겨, 해석을 달은 것입니다. 일단 기존에 코드가 어떤 문제가 있었는지, 예제 코드를 통해 이해해보겠습니다. ..
issue number #8524에서 JoinColumn에서의 제약 조건 이름을 추가하는 법이 추가되었습니다. 이 내용은, 기존의 방식처럼 Entity 위에 @index() 데코레이터를 통해 제약조건을 거는 것보다 명시적입니다. 인덱스 데코레이터의 경우에는 하나의 데코레이터를 이용해 Primary와 복합키, 외래키 등을 모두 표현했습니다. 따라서 그 의미가 무엇을 뜻하는지는 인덱스 데코레이터와 엔티티 칼럼과의 관계를 보고 이해해야 했습니다. issue number #8900에서는 위의 변화와 더불어 Column 데코레이터에서도 제약조건 명시를 허용했습니다. 새로이 명시된 방법은 아래와 같습니다. @Entity() export class Post { @ManyToOne((type) => Category) ..
대기업, 스타트업, 그리고 어떤 회사냐에 따라 좋아하는 개발자 유형은 다르다. 하지만 공통적인 부분을 뽑으라고 한다면, 아마 비즈니스에 대한 이해도가 있는 개발자일 것이다. 무엇을 만들어야 하는가. 그건 바로 돈이 되는 코드다. 돈이 되는 코드라는 건, 최적의 노력으로 최대의 효용을 낼 수 있는 코드다. 아무리 멋진 코드를 짠다고 하더라도 유저들이 찾지 않는 기능은 죽은 기능이다. 그러니 만들어달라는 요구대로 만들기만 하는 개발자가 아니라, 왜 만들어야 하는지에 대해 설득을 요구하는 개발자가 되어야 한다. 기획자, 디자이너에게 계속 해서 반문해야 한다. 이게 정말로 우리의 유저가 원하는 것인지- 애초에 그 사람들이 정말 우리의 유저 정의에 부합하는지- 일일히 따지고 들어서 딱 필요한 것만을 개발할 수 있..