kakasoo

원래 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) ..

대기업, 스타트업, 그리고 어떤 회사냐에 따라 좋아하는 개발자 유형은 다르다. 하지만 공통적인 부분을 뽑으라고 한다면, 아마 비즈니스에 대한 이해도가 있는 개발자일 것이다. 무엇을 만들어야 하는가. 그건 바로 돈이 되는 코드다. 돈이 되는 코드라는 건, 최적의 노력으로 최대의 효용을 낼 수 있는 코드다. 아무리 멋진 코드를 짠다고 하더라도 유저들이 찾지 않는 기능은 죽은 기능이다. 그러니 만들어달라는 요구대로 만들기만 하는 개발자가 아니라, 왜 만들어야 하는지에 대해 설득을 요구하는 개발자가 되어야 한다. 기획자, 디자이너에게 계속 해서 반문해야 한다. 이게 정말로 우리의 유저가 원하는 것인지- 애초에 그 사람들이 정말 우리의 유저 정의에 부합하는지- 일일히 따지고 들어서 딱 필요한 것만을 개발할 수 있..

커머스마다 돈 계산하는 방법은 다 다르다. 다만, 모든 사이트에서 공통적으로 사용될 수 있도록 다이어그램을 하나 만들어봤다. 결제 금액 계산하는 법 장바구니 가격 계산 상품 가격 계산 ( 옵션과 선택 옵션의 가격과 수량 곱의 합 ) 옵션 가격 계산 상품의 가격과 옵션 수량의 곱 선택 옵션 가격 계산 상품 가격과 선택 옵션 수량의 곱 배송비 책정 각 상품 당 배송비 책정 상품 정보나 배송지 정보가 누락된 경우 배송비 0원 ( 비정상적인 경우 ) 도서산간지역인 경우 도서산간지역 배송비를 책정 도서지역 배송비보다 상품의 배송비가 큰 경우, 큰 쪽을 우선 ex. 배송비가 40,000원인 경우 도서지역 배송비인 5,000원보다 크게 된다. 배송비가 무료인 경우 0원. 배송비가 유료인 경우, 상품의 배송비로 고정...

최근에 그로스 해킹에 대해서 배운 탓에, 회사에서 일하던 것에도 동일한 고민을 할 수 있었다. 고민하는 게 재밌는 건 오랜만의 일이라, 협업하고 있는 디자이너 겸 기획자님에게도 내 고민을 공유했다. 함께 고민했으면 하는 마음과 함께, 이 분께서도 이 재미를 느낄 수 있기를 바랐다. 내가 하고 있는 고민은 아래와 같다. 정작 만들었는데 아무도 안 쓰면? 우리는 알림 기능을 세분화해서 제공한다. 각 기능마다 알림 기능이 있고, 이 기능을 원하는대로 ON/OFF할 수 있다. 만약 우리가 만든 기능 중 대부분의 유저가 알림을 끄고 있다면 우리는 이걸 어떻게 해석해야 할까? 알림 기능은 대부분 서비스가 제공하는 기본적인 기능이기 때문에 유저들의 사용이 저조하다고 해서 없애자고 할 기능은 아니다. 하지만 그건 알림..

이 글은 Node.js를 더 잘 다루기 위해 비동기 제어를 설명합니다. 일부러 돌아가는 길을 선택함으로써 일반적으로 사용하지 않았을 법한 것을 설명합니다. 구글 페이지 가져오기 import axios from "axios"; async function getWebContent(url: string) { const { data } = await axios.get(url); return data; } (async () => { await getWebContent("https://google.com"); })(); 즉시 실행 함수 형태로 구글의 메인 페이지 문서를 읽는 코드를 작성했습니다. 간단합니다. 다음으로는, 이를 10번 반복하는 함수를 만들 것입니다. 비동기적으로 구글 페이지 10번 가져오기 impor..

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