kakasoo

친구들이 부스트캠프에 지원한다고 한다. 내가 부스트캠프를 지원한 것은 2년 전이다. 부스트캠프 덕분에 내 실력이 크게 늘었고 ( 수료 후에 공부한 것도 정말 많았지만, 이 역시 공부하는 방법을 가르쳐 준 부스트캠프 덕이라고 믿는다. 또한, 부스트캠프에서 만난 사람들과, 2년이 지난 지금까지도 매주 주말 스터디를 진행했으니 이 또한 부스트캠프 덕이다. ) 부끄럽게도, 친구들은 내 모습에 자신을 투영한 모양이다. 자신들도 부스트캠프에 가면, 나처럼 뭔가 익혀올 수 있을 거라 믿는 모양이다. 아직 나 스스로도 부족한 점이 많다고 생각하지만, 그렇게 생각해주는 친구들에게는 무척이나 고맙다. 그리고, 친구들도 좋은 기회를 얻을 수 있기를 바란다. 친구들의 기대감이 충족되기를 바라며, 친구들의 질문에 답하며, 나 ..

const readline = require("readline"); const rl = readline.createInterface({ input: process.stdin, output: process.stdout, }); let number; rl.on("line", (line) => { if (!number) { number = Number(line); } else { const revsered = line .split(" ") .map((word) => word.split("").reverse().join("")) .join(" "); console.log(revsered); } }); 각 문장을, 띄어쓰기 단위로 자른다. 단어가 된다. 단어를 글자 단위로 자른다. 글자를 뒤집어서 다시 합친다. ..

결론부터 말하자면, 시스템 설계에서 가장 적합한 부하 매개변수를 고른 정한 다음, 그걸 기준으로 부하를 판단해야 한다. 트위터에서는 팬 아웃이라는 용어를, 트윗 1건 당 팔로워에게 전송해야 하는 메시지의 수를 설명하는데, 이와 같은 SNS 사례는 서버 측이 겪을 수 있는 가장 큰 트래픽 중 하나를 보여준다. 확장성의 의미 시스템의 데이터 양, 트래픽, 복잡도가 증가하면서, 이를 처리할 적절한 방법들이 필요해진다. 시스템이 현재 안정적으로 동작한다고 해서 미래에도 안정적으로 동작할 거란 보장은 없다. 성능 저하를 유발하는 흔한 이유 중 하나는 부하 증가다. 사용자의 수는 단순히 10배 증가했다고 할 수 있지만, 그게 10만에서 100만으로, 100만에서 1,000만으로 증가하는 등, 절대적인 수에서도 큰 ..

300-399: 리다이렉션 상태 코드 리다이렉션 상태 코드는 클라이언트가 관심있어 하는 리소스에 대한 다른 위치를 사용하라고 말해주거나, 리소스 대신 다른 대안 응답을 제공한다. 리소스가 옮겨졌다면 어디서 찾을 수 있는지 알려주기 위해 리다이렉션 상태 코드와 Location 헤더를 보낼 수 있다. 이는 브라우저가 사용자를 귀찮게 하지 않고, 알아서 새 위치로 가게 해준다. 이런 특성으로, 리다이렉션 상태 코드 중 일부는 로컬의 복사본이 원래 서버와 비교했을 때 유효한지, 또는 최신의 파일이 맞는지 비교하는 데에 쓰인다. 이 때에는 If-Modified-Since 헤더에 특정 날짜를 보내 그 날짜를 기준으로 파일의 수정이 생겼는지 체크할 수 있다. 이 경우 304의 상태 코드가 돌아온다. 일반적으로, HE..

I agree with you. There is a problem here. LoadRelationCountAndMap is mapped, but does not work properly when sorted, and addSelect is not mapped, but can be sorted. Eventually, there is a problem of having to use both. query .loadRelationCountAndMap('user.itemCount', 'user.items', 'itemCount') // mapped, but can't be sorted. .addSelect((qb) => { return qb.select('COUNT(item.id)', 'count').from(..

데이터의 양, 복잡성, 변하는 속도 등 데이터가 주요 도전 과제인 애플리케이션을 데이터 중심적이라 한다. NoSQL, RDB, message Queue, cache, index, 일괄처리 또는 스트림 처리 프레임워크 등, 애플리케이션은 데이터를 다루기 위한 많은 기술들을 조합해서 사용하는데, 이 기술들의 트레이드오프를 올바르고 정확하게 이해해야 한다. 다행히도 이런 기술들에는 변하지 않는 원리가 있다. application 개발 방법 변천의 원동력 대기업들이 가진 엄청난 양의 데이터와 트래픽을 다루기 위한 효과적인 도구 필요 Lean하게, 적은 노력으로 가설을 테스트하고 시장을 빠르게 검증할 필요 CPU의 병렬 처리 ( 멀티코어 ) 성능 향상과 고성능 네트워크 AWS 같은 IaaS 덕택에 소규모 팀도 쉽..

개발자들에게 중요한 것은 기술 스택이다. 하지만, 무조건 기술 스택만 중요한 건 아니다. 커머스에서 일한 개발자라면, 다음 직장 역시 커머스일 때, 당장의 기술 스택이 다르더라도 일단 와서 배우라고 말할 수 있다. 기술 스택 말고도 분야에 대한 이해도가 있는지, 시리즈 ( 투자 라운드 ) 에 따라 자신이 수행해야 할 역할을 이해하고 있는지, 창업가 정신을 가지고 있는지, 조직을 리드해본 경험이나 인간관계에 대해 깊이 고찰해본 경험이 있는지도 고려할 부분이다. 똑같은 기술 스택을 가진 사람이라고 하더라도, 커머스 개발자는 커머스 개발자고, 게임 서버 개발자는 게임 서버 개발자가 될 것이다. 또 제너럴리스트가 있다면 스폐셜리스트가 있을 것이고, 경력이 쌓여가면서 기술 스택으로 구분되는 일이 점차 적어질 것이..

누군가 힘들다고 할 때, 그 사람이 정말로 힘든건지, 그냥 빼고 싶어서 하는 말인지 어떻게 구별하는가. 그리고 그 사람이 똑같은 시간을 일했더라면, 책임감이 있고 없고를, 도대체 무슨 수로 판단하는가? 또한, 만약 그 사람이 해도 안 된 거라면, 그건 어떻게 알아챌 것이며, 해도 안 된 것에는 책임이 없다고 할 수 있는가. 지금까지 이야기한 것들에 대해 알 방법이 없다면, 우리는 앞으로 어떻게 사람을 믿어야 하는가? 만약 불가능하다면, 조직 차원에서 행할 수 있는 당장의 대책은 무엇이고, 앞으로 재발 방지를 위해 노력할 것은 뭔가? 누군가를 저격하기 위해 쓴 글이 아니고, 나에 대해서 돌아본 것이다.

typeorm shychronize 시 발생하는 CannotExecuteNotConnectedError는 한 entity로부터 연결되어 있는 다른 entity를 발견하지 못한 경우, 즉, Relation을 발견하지 못한 경우에 발생하는 것으로 보인다. 이 상태에서 서버를 실행할 경우, metadata A was not found. 라는 error message가 나오는데, 이 error message의 경우, 어떤 칼럼이 아니라 relation을 찾지 못한다고 나온다. 이 에러들의 경우, ormConfig, 또는 typeorm 설정에서 특정 entity를 찾지 못한 경우 발생한다. ( 만약 전부 다 찾지 못하는 상황이면 다른 message 가 나온다. ) 따라서, 경로를 와일드카드를 사용해서 작성한 경우..

공정하려면 최저, 또는 최대치인 사람을 기준으로? 최근에 든 생각이다. 우리 회사에서는 직원들 복지로, 직원들이 필요한 물건을 직접 신청할 수 있는데, 신청 물품으로 '고데기'가 올라왔다. 이로 인해서, 이게 복지에 포함될 수 있는지에 대해 생각하게 되었다. 단순히 여자만 사용할 수 있기 때문에 직원 복지가 될 수 없다는 건 너무나 편협한 생각이다. 당장 생각나는 것은 없지만, 남성만 사용할 수 있는 물건이 생길 수도 있는 것이고, 굳이 성별로 나누지 않더라도 '특정 누군가가 자주 이용하는 물건'이 복지가 될 상황은 많은데, 이게 적절한 복지인가? 묻는다면, 고개를 갸우뚱하게 되는 것들이 점차 늘어날 것이다. 가령 회사의 맥주 및 음료수 제공은, 음주를 하지 않거나 다이어트 중인 사람에게는 불필요한 복지..

인터넷에 이 둘의 장단점에 대한 많은 글이 있지만, 그래서 뭘 써야 하는지 결론은 없어서, 뇌피셜을 적는다. 토큰과 세션의 차이 예전에는 서버가 모든 걸 해주었다. 결혼식 방명록을 session이라고 해보자. session은 방명록처럼, "유저 1이 왔다 갔습니다." 라고 적는 방식이다. 이 때, 서버의 유저 수가 몇 천, 몇 만을 넘으면 어떻게 될까? 모든 걸 기록 하는 방식인 세션에서는 "야, 저번에 축의금 낸 사람 누구지?" 라는 질문에 답하기 위해서, 로그를 뒤져봐야 하는 수고를 해야 한다. 세션은 유저의 인증을 위함인데, 이 인증 자체가 서버에 큰 부하를 주게 된다. 물론, 이 경우 서버의 수를 늘리면 해결할 수 있다. 하지만 여러 명이 방명록을 나눠 적는 셈이니, 서로의 기록이 달라지게 된다...

// NOTE: 예시로 작성한 코드 async searchUser(search: string, orderName: string, order: 'DESC' | 'ASC') { let query = this.userRepository .createQueryBuilder('user') .leftJoinAndSelect('user.department', 'user') .where('user.isBot = false'); if (search) { query = query.andWhere('user.name ILIKE :search OR department.name ILIKE :search', { search: `%${search}%`, }); } if (orderName && order) { return awai..