kakasoo

이 글은 위키북스, 양승화 저자님의 그로스해킹을 읽고 정리한 내용입니다. 과업 기반은 각 팀마다 목표를 정해서 진행하기 때문에 수시로 기준이 바뀔 수 있을 뿐더러, 전체의 방향을 알 수 없고 각 팀이 정한 지표들 중 어느 쪽이 더 중요한 지표인지 알 기 어려워진다. 또한 내가 오늘 놀지 않았다는 걸 증명하는 수단으로 변질되기 쉽다. 중요한 건 일을 많이 하는 게 아니라 우선순위가 높은 일에 집중해 성과를 만드는 일이다. 더 효율적으로 지표를 관리하기 위해서는, 회사 조직도에 따라 지표를 각각 관리하지말고, 사용자의 서비스 이용 흐름에 맞춰 지표를 관리해야 한다. 즉 유저가 들어오고 나가는 각 단계를 포괄하는 퍼널(funnel)을 만들고 각 단계에서 핵심 지표를 찾아야 한다. 이러한 맥락에서 가장 효율적으..

2.6.6. 비동기 임포트 ESM의 단점은, 모듈 식별자를 실행 중에 생성할 수 없다는 점, 모든 파일의 최상위에 선언되어 제어 구문 내에 포함될 수 없다는 점이다. 이는 사용자에 따라 다른 모듈을 불러야 하는 경우에 지나친 제약이 될 수 있다. 따라서 이를 극복하기 위해 비동기 임포트 ( 동적 임포트 ) 를 제공한다. if(true) { require(a); } else { require(b); } // strings-ko.js export const HELLO = '안녕하세요.' // strings-jp.js export const HELLO = '오하이요'; // strings-en.js export const HELLO = '하이' const SUPPORTED_LANGUAGES = ['ko', '..

ESM : ECMAScript 모듈 사실 CommonJS는 표준이 아니에요. 조금 역사를 이야기할 필요가 있는데, 아시다시피 JavaScript는 프론트 언어였습니다. 그런데 프론트에서는 HTML 문서 상에 script 태그를 이용해서 JavaScript 코드를 전역 상태로 사용하곤 했죠. 그러다 보니 당연히 모듈이 필요없었어요. 모든 게 하나의 전역 코드니깐요. 그렇지만 백엔드에서도 JavaScript가 쓰이기 시작하면서 모듈 시스템에 대한 고민이 생겨났고, 그 결과 사용자들이 고안해낸 게 CommonJS였죠. 그렇지만 이 CommonJS는 표준이 되지는 못했습니다. 아마도 그 이유는, ECMAScript가 프론트, 백에 따라 같은 언어, 다른 표기로 나뉘는 걸 꺼렸기 때문인 거 같아요. 그래서 ECM..

이 글은 Node.js 디자인 패턴 바이블이라는 책을 기반으로 하고 있어요. 이 글은 CommonJS에 대해서 말하고 있어요. 이 글은 원래 스터디 발표 용도로 작성된 거에요. 😎 require() : 해결 (resolve) 알고리즘 const myJsCode = require("./myJsCode"); // .js는 생략 가능하다. const path = require("path"); const express = require("express"); 해결 알고리즘은 크게 다음 세 가지로 나눌 수 있어요. 파일 모듈 : 상대 경로로 작성되었는가? 코어 모듈 : 파일 명만이 언급되었는가? 패키지 모듈 : 코어 모듈에서 해당 파일을 찾을 수 없는가? ( => node_modules) 우리는 require로 이..

차근차근 Nest에 대해서 설명하고자 한다. 이 글에서는 Controller와 Service, Repository를 어떻게 구분하면 좋을지를 설명한다. 당연히 각 역할대로 구분하면 된다는, 간단한 소개가 되겠지만, 그 각 역할이 뭔지 이야기 해보자. Module @Module({ imports: [OtherModule], controllers: [SomeController], providers: [SomeService], exports : [SomeService], }) export class SomeModule {} Express 유저라면 처음 Nest를 접하고 나서 이해되지 않는 내부 동작에 놀랄 것이다. 너무 친절한 나머지 개발자가 이해해야 할 부분까지 다 알아서 해버리니 말이다. 그래서 아무렇게나..

Entity 정의 상품의 Entity 정의 /** * 상품의 Entity */ @Entity('product', { schema: 'db_name' }) export class Product { @PrimaryGeneratedColumn({ type: 'int', name: 'idx' }) idx: number; @Column('varchar', { name: 'title', length: 255 }) title: string; } 해시태그의 Entity 정의 /** * 해시태그의 Entity */ @Entity('hashtag', { schema: 'db_name' }) export class Hashtag { @PrimaryGeneratedColumn({ type: 'int', name: 'idx' ..

정적 모듈에서는 환경 변수 사용 불가 이번 글은 짧은 내용을 다룬다. 아마 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 커뮤니케이션 비용 “의사소통에도 비용이 든다.” 저는 개인적으로 이런 사실이 의아했습니다. 스타트업은 각자 개인의 성공을 위해 모인 조직인데, 이런 비효율이 용인할 수 있는가? 우리의 성공도 결국은 각자의 성공을 위함인데 왜 비효율을 한 켠에 방치해두겠는가? 우리의 말 한 마디로 비효율을 타파할 수 있다면 기꺼이 타파하는 게 맞지 않은가? 안타깝게도 아니었습니다. 이성..