kakasoo

정적 모듈에서는 환경 변수 사용 불가 이번 글은 짧은 내용을 다룬다. 아마 dotenv를 사용하다가 Nestjs와 ConfigModule을 사용하려던 사람들은 시행착오를 많이 겪을 것이다. 사실 TypeORM을 써서 발생하는 문제는 아닌데, 이런 상황을 주로 만나는 게 아무래도 ORM일 것 같아서 제목에도 넣었다. Nestjs에는 ConfigModule이 있다. ConfigModule을 사용해서 미리 .env를 삽입해두면 그 하위 모듈에서는 모두 process.env를 통해서 값에 접근할 수 있게 된다. 하지만 아래 같은 경우를 보자. // nestjs recipe의 typeORM 문서를 보면 아래의 예제 코드가 있다. import { Module } from '@nestjs/common'; import..

서론 const router = express.router(); // express CRUD router.post('/', controller.postMethod); router.get('/', controller.getMethod); router.put('/', controller.putMethod); router.delete('/', controller.deleteMethod); Express에서는 다음과 같이 CRUD를 만든다. 사실 간편하고 빠르게 서버 어플리케이션을 확장할 수 있다는 게 장점이다. 하지만 Express는 구조적으로 짜임새가 있지는 않다. 그래서 결국에는 차세대 프레임워크에게 자리를 물려줄 것으로 보인다. 이제부터 직접 두 프레임워크를 다루면서 느꼈던 차이점, 그리고 Express..

서비스를 구현하다보면 당연히 여러 사용자가 존재하게 된다. 이 사용자라는 표현은, 그냥 내 임의로 부르는 호칭인데, 말하자면 유저의 성격이다. 예컨대 커머스라고 한다면 구매자와 판매자, 관리자가 있을 수 있고, 예약 서비스를 만든다면 식당 주인과 손님이라는 관계가 생길 것이다. 대개 서비스라고 함은 하나의 사용자만 존재할 리 없고, 하다 못해 관리자를 포함해 둘 이상의 사용자가 반드시 존재할 수 밖에 없다. 문제는 여기서 발생한다. "서로 다른 사용자를 어떻게 한 서버 내에서 인증하는가?" PassportStrategy에 이름 설정하기 우리가 사용하는 Gaurd들에 대해서 다시 고찰해볼 필요가 있다. Guard들은 어떻게 자신에게 할당된 전략을, 알아서 찾아가는 걸까? import { Injectable..

import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common'; import { Reflector } from '@nestjs/core'; import { InjectRepository } from '@nestjs/typeorm'; import { User} from 'src/entities/user.entity'; import { Role } from 'src/common/common.enum'; import { Repository } from 'typeorm'; import { ROLES_KEY } from '../roles/back-office-roles.decorator'; @Injectable() export class Ad..

좋은 팀이란 무엇일까? 회사의 성장은 기세를 타면 기하급수가 된다. 어제와 오늘이 다르다고 할 정도로 명확하긴 힘들지언정, 저번 달과 이번 달이 다를 정도로는 성장할 수도 있다. 하지만 개인의 성장은 배로 증가할지언정 제곱의 성장을 바라서는 안 된다. 심지어 누군가의 성장은 기업과 무관하게 정체되어 있을 수 있고, 애초에 본인도 그렇게 바라고 있지는 않을 수 있다. 가령, 나는 지금 이 정도 수준으로도 충분히 먹고 살 만한데 굳이 더 힘들게 노력을 해야 하는가? 이런 판단도, 개인의 삶에서 추구하고자 하는 가치가 다른 거라고 생각하면 충분히 이해할 만 하다. 일과 삶의 균형에서 어느 쪽에 더 무게를 둘 것인지는 사람마다 천차만별이라, 삶이 있기에 일이 있다고 생각하는 게 나쁜 것은 아니다. 하지만 스타트..

원칙 ( Principle ) 원칙은 ‘레이 달리오’가 자신의 회사를 이끌면서 경험한 내용을 정리한 책입니다. 이 문서는 제가 그 책을 읽고 정리한, 일종의 편지글입니다. 온전히 뜻을 전달하긴 힘들어 인용을 최대한 했으나, 책의 내용에 비할 바는 아닌 것 같습니다. 관심이 있으시다면 꼭 이 책을 읽어보시길 권하고 싶습니다. 22.01.28 커뮤니케이션 비용 “의사소통에도 비용이 든다.” 저는 개인적으로 이런 사실이 의아했습니다. 스타트업은 각자 개인의 성공을 위해 모인 조직인데, 이런 비효율이 용인할 수 있는가? 우리의 성공도 결국은 각자의 성공을 위함인데 왜 비효율을 한 켠에 방치해두겠는가? 우리의 말 한 마디로 비효율을 타파할 수 있다면 기꺼이 타파하는 게 맞지 않은가? 안타깝게도 아니었습니다. 이성..

이 글은 과거에 쓰고 미처 올리지 못한 글이라, 글의 시점이 지금보다 더 이전이다. 연봉협상을 처음 한 신입의 심리 내가 생각하는 게 있는데, 그게 상대의 생각과 같을까, 그걸 잘 모르겠어. 말을 해도 될까. 하지만 서로 생각이 달라서, 결국 관계만 훼손시키고 끝나는 게 아닐까, 그게 두려워. 아니, 오히려 상대에 대한 실망보다도 이 생각이 나만의 생각일까봐, 그게 더 두려워. ...하지만 말하지 않으면 해결되는 건 아무것도 없다지. 그래, 결국은 말해야겠지. 말하는 게 맞을 거야. 설령, 이 관계가 망가진다고 하더라도, 그러는 게 맞아. 나는 상대가 아니라, 내 이기심만을 챙기는 게... 아마 맞을 거야. "오빠, 딴 여자 생겼어?" "아니, 연봉협상 얘기야..." 애초에 말하지 않아도 상대가 알아주길..

여러 가지 엔티티의 칼럼이나 프로퍼티를 통일시켜, 하나의 함수를 여러 엔티티가 공유할 수 있게 작성하고 싶다. 그렇지만, 파라미터로 오는 타입들이 다른 경우, 이렇게 만드는 게 쉽지 않다. 이런 경우에는 직접 커스텀한 함수로 타입을 보호해줄 수 있는 방법이 필요하다. public format(value: Foo[] | Bar[]) { const isFooArray = isArrayOf(isInstanceOf(Foo)); if (isFooArray(value)) { // true block for (const foo of value) { const f: Foo = foo; // okay } } else { // false block for (const bar of value) { const b: Bar =..

지금 생각해도 설레는 Boostcamp. 부스트캠프를 수료할 때 저는 3학년이었다. 부스트캠프에서의 반 년은 제 인생 더 없을 정도로 폭발적인 성장이었지만, 여전히 제 스스로에 대한 의문은 남아있었다. 아무리 잘 성장했다고 하더라도 내가 공부를 시작한지 이제 막 1년이 되었기에, 자신감을 가지기가 힘들었던 것 같다. `내가 어디까지 갈 수 있을까?` 항상 하던 고민에, 결국 다시 대학으로 돌아가는 선택을 했다. 사실 잘 찾아보면 부스트캠프에서 취업 연계로 더 좋은 기회가 있을지도 모르는데, 자존심을 지키려던 선택은 아니었을까. 대학에 돌아오고 나서 다시 한 학기의 시간을 보내면서, 부스트캠프가 그리워졌다. 그 때처럼 힘들어도 계속 성장한다는 느낌을 받고 싶었고, 그래서 우연찮게 한 스타트업에 가게 되고,..

성능 기술하기 부하 매개 변수를 증가시키고 시스템 자원은 그대로면 성능은 어떻게 될까? 부하 매개변수를 증가시켰을 때 성능을 그대로 하려면 자원은 얼마나 늘려야 할까? 두 질문 모두 성능수치가 필요하다. 하둡 (Hadoop) 같은 일괄 처리 시스템은 보통 처리량 ( throughput ) ( 초당 처리 가능한 레코드 수나 일정 크기의 데이터 집합으로 작업을 수행할 때 걸리는 전체 시간 )에 관심을 가진다. 온라인 시스템에서 더 중요한 사항은 서비스 응답 시간 ( response time ), 즉 클라이언트가 요청을 보내고 응답을 돌려받기 까지의 시간이다. 클라이언트가 몇 번이고 반복해서 동일한 요청을 하더라도 매번 응답 시간은 다르다. 이 때, 대부분의 요청은 꽤 빨라도, 특히 오래 걸리는 특이 값 ( ..

시작하기 전에 블록체인을 어떻게 활용할 수 있을까. 최근에 읽고 있는 책에서는 데이터를 저장하고 꺼내는 데 사용하는 도구 5가지를 가르쳐줬다. 이 5가지 도구는 우리가 잘 아는 데이터베이스부터 캐시와 인덱스, 메시지 큐, 배치 시스템 이렇게 5가지다. 나는 이 책에서 말한 것과 같이, 백엔드가 이제는 데이터 도구들을 엮는 역할만 수행할 거라는 점에서 언뜻 동의한다. 서버는 이제 데이터를 꺼내고 저장하는 모든 연산을 외부 도구들에게 맡길 것이고, 데이터의 형태를 변환하는 등의 최소한의 연산을 제외한다면, 이 도구들 간의 커뮤니케이션을 수행하는 데 대부분의 자원을 사용할 것이라는 생각이다. 다만 언뜻이라고 말한 부분은, 내가 좋은 의미로도 나쁜 의미로도 아직 주니어 개발자이기 때문이다. 확신은 할 수 없다...

오랜만에 친구와 만나 이야기를 했다. 친구는 새로운 커리어를 고민 중이었다. 지금까지 하던 일과 아예 다른 일을 할지도 모른다고 한다. 모든 가능성을 열어놓고, 새로운 길을 모색하고 있다고 한다. 이 친구는 개발자도 아닐 뿐더러, IT 직군에서 일하는 사람도 아니고, 오히려 공기업에서 일하는 친구였지만, 맥락은 충분히 이해될만한 말이었다. 이 말은 나도 크게 공감하는 일이다. 나도 언젠가 개발 외의 다른 일을 할지도 모른다는 생각을 자주 한다. 그도 그런 게, 개발 쪽은 기술 발전의 속도가 매우 빠르다고 한다. 개발자 잡지인 readIT에서 NHN 클라우드 부문 CTO인 김명신님의 글을 본 적이 있는데, 이 분야는 18개월 마다 지식의 반이 무용지물한 것이 된다고 한다. 그래서 이를 지식의 반감기라고 부..