Sn._.Jay

페인포인트 : ElasticSearch에 센서 시계열 데이터들이 쌓이고 있는데 이게 끊겨도 얼럿이 오지 않고 있다. 그래서 문제가 생겨 끊겨도 즉각적으로 알지 못 하고 그냥 날려버릴 때가 있음 대안 : 데이터가 끊기면 슬랙 얼럿을 보내주자! 조건 1 : 한번 발송하고 나서 다음 날 까지 다시 발송해주지 않았으면 좋겠음 조건 2 : 그러고 하루 지나면 다시 발송 조건 3 : 모든 센서에 대해서 체크, 발송하는게 아니라 센서당 특정 값에 대해서만 대표값으로 모니터링 조건 4 (이건 나만의 기준) : 하반기 AWS 비용 줄이기 대작전을 하고 있는 중이기 때문에 비용 최대한 안 들어가게 해보자 첫번째 아이디어 : ES 데이터를 담당하는 Repository에 node schedule > cron을 통해 1시간마다..

> 새로운 회사를 오고 이전 회사에서 안 쓰는 AWS 서비스들을 많이 사용하고 있다. 이에 이름만 알고 있었던 서비스들에 대해 어떤 서비스이고 어떤 역할을 하는지 간단하게 어떻게 사용하고 있는지 정리하고자 한다. Amazon Cognito 유저 인증 관리 및 유저 정보를 관리해주는 서비스 > 우리가 유저 Table을 만들고 관리할 필요가 없어짐 Amazon Amplify (Cognito와 세트) 쉽게 말하면 그냥 모든 개발회사가 만드는 로그인, 회원 가입과 같은 유저 관련 기능을 제공하는 서비스이다. > 백엔드 개발자가 따로 로그인 및 유저 관련 API를 개발할 필요가 없어짐 Druid (쓰려고 했던 것) vs. Amazon Elasticsearch (쓰고 있는 것) AWS elasticsearch는 처..

개발자에 지대한 영향을 주는 회사의 요소는 단연코 그 회사의 PR문화라 할 수 있다. 이건 대부분의 개발자가 알고 있고 시행을 하고자 하지만 보통 높은 확률로 바쁘다는 이유로, 크게 도움되지 않는 다는 이유로 시행되지 않기도 한다. 내가 지금 있는 셀러노트도 PR문화는 그래도 나쁘지 않았고 많은 리뷰도 받고 내가 리뷰를 하며 새로 알게된 것들도 많았다. 그리고 최근 개발자 인원이 많아지면서 지금까지는 인력이 적어 어쩔 수 없었던 것들에 대해 어떻게 개선해 볼 수 있을지 정리 해보자 한다. > 코드 리뷰의 목적 실수를 줄이는 것 아예 돌아가지 않는 실수가 있고 (오탈자 등) 개선의 여지가 명확히 보이는데 급하게 개발하며 놓치고 비효율적으로 개발하는 실수가 있다. 전자는 테스트 코드나 로컬 테스트를 통해 ..

> 막연하게 백엔드 개발자를 시작하며 API 개발을 시작했고 그 안에서 REST API에 최대한 맞춰 개발을 하고자 했었다. 그리고 GraphQL이 프론트쪽에서 핫하다고 하면서 본 내용 중 Rest API의 고질적인 문제점을 보는데 이게 딱 지금 내가 개발하는 API의 문제점이라 생각하고 있는 것들과 겹쳐서 기술한다. = 즉 특정 화면에서의 내가 지금 머리아파는 문제를 GraphQL로 해결 가능할 수도 있다. REST API의 문제 (Over-fetching, Under-fetching) Over fetching : 말 그대로 불필요한 데이터까지 API 결과값에 포함되어 return되는 것을 말한다. 최근 내가 쉽다 API 리팩토링 한 내용 중 하나가 이러한 문제들 때문에 return interface를..

더보기 effective typescript를 스터디하면서 나온 'readOnly는 얕게 적용된다'라는 말에 대한 개념을 명확하게 정리하기 위해 씀 > 일단 Call by Value와 Call by Reference에 대한 내용은 구글링 하면 무수히 많이 나온다. 하지만 어떤 언어를 사용하냐에 따라 이에 대한 이해는 좀 다르게 해야한다. Call by Value와 Call by Reference에 대한 기본적인 개념 기술 후 내가 사용하는 Typescript(=Javascript)에서는 어떻게 이에 대한 처리가 되고 있는지 정리한다. const a = { a: 5 }; const testFunction = (b) => { b.a = 1; return b; }; const testFunction = (c)..

현재 지금 우리 구조는 왼쪽의 구조와 같았다. Ship-da API, Admin API, 이메일&문자&잔디 알람 발송, 크론잡 코드들이 Monolith하게 구성되어있었음 그리고 여기서 이제 신규 WMS서비스에 대한 repository가 추가되고 이메일, 문자 발송에 대한 기능과 거래명세서, 견적서 생성 기능을 별도 서버를 분리하자는 움직임이 있었다. (이 기능은 신규 WMS에서도 사용을 해야하니깐) 그리고 이에 따라 MSA스러운 성격을 띄게 되었는데 MSA 구조를 도입하진 않을 예정이지만 이러한 구조를 더 편히 관리하기 위하여 모노레포를 도입하기로 하였다. 이 전에 기존 모노리스 (Monolith), 멀티레포 (Multirepo), 모노리포(Monorepo)의 특징과 성격을 정리하고자 한다. 모노리스 (..

2주짜리 스프린트가 3주짜리 스프린트가 되고 1주일 지옥 문턱까지 보고 방금 배포 다 올린다음 확인하고 풀린 다리로 지금 머리 속에 있는 내용 정리하다래ㅑㅁㅈ두랴ㅐㄷㅈ > 이번 스프린트의 가장 큰 패착 티켓 업무 이름에 낚여서 방심했다. '운영트렐로 수정 및 관세청 연동'이라는 정말 지극히 평범한 일상같은 업무의 제목을 보고 나는 그냥 당시 쿠폰팩 개발의 마무리 단계에 있었기에 대략적으로 생각나는 것들의 업무를 생성해서 일정을 짰다. 결론적으로 아니였다. 개발하다 보니 그냥 제목은 낚시 기사 제목이였다. 운영 담당자들이 사용하는 운영트렐로는 수정이 아닌 전면 리뉴얼이였고 기존에 수출입 건들의 각각의 수출입 단계 (status값)을 전면 단축하는 마이그레이션까지 필요했다. 그리고 관세청 실시간 정보들이 운..

이번 시스템 리뉴얼 배포때문에 지옥 문턱까지 보고 돌아온 기념 까먹기 전에 일단 이슈 정리 함 이번 리뉴얼 중 메인 골자 중 하나가 자동화임 주기적으로 수출입건에 대해 관세청 API를 조회해야했고 aws 람다를 통해 30분마다 크론잡을 돌려주기로 하였음 문제는 관세청 API를 매건 호출해야하는 것도 문제인데 이 중 특정 조건을 성립하는 수입건은 update도 해주고 고객사에 안내메일도 보내줘야 했다. 이걸 cron job에서 쏘는 리퀘스트 하나로 처리하면 분명 문제가 될 것이라 Unipass 이후의 작업에 대해서는 따로 또 분리하여 처리를 해주려고 함 따로 처리를 해주려고 하는 친구 후보 AWS SNS : 이미 많이 사용 중인 친구임. 사실 최근에 이메일, 문자 발송 서비스는 aws가 아닌 postmar..

이번 장은 실제 오픈 소스 라이브러리를 리팩로팅하는 페이지이다 TestCode의 커버리지는 최대한으로 높여야 한다. 그리고 테스트 코드의 버그는 없어야 한다. 주석 변경까진 이력 변경은 하지 않아도 되고 불필요한 주석은 바로바로 지워야 한다. 클래스, Function의 이름은 적절하게 지어야 한다. static final 상수 모음보다 enum을 사용한다. 부모 클래스는 자식 클래스에 대한 정보를 모르는 것이 구조적으로 옳다. if의 연쇄도 enum으로 옮길 수 있다. 일반적으로 Function 인수로 플래그 값은 바람직하지 못 하다...

- 요즘 공부를 하면서 전회사에서 꼴에 클린 코드를 지향하며 하였지만 개발자들 간에 규칙을 정하지 않고 문서화를 하지 않으시는 분들이 많아 깨끗한 것과 거리가 멀어졌었는지를 느낀다.. 다시 그 때를 복기하고 지금과 비교하며 책을 정리해본다 관심사 분리 어플리케이션을 서로 겹치지 않는 개별 단위로 나누는 과정 즉 잘게 잘 쪼개야한다는거 이 때 객체를 생성하거나 의존성을 연결할 때 모듈성이 깨지지 않게 해야하고 관심사를 잘 분리해야 이를 높게 유지할 수 있다. 시스템 생성과 시스템 사용을 분리해야한다. 생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮긴다. 모든 의존성이 main에서 애플리케이션으로 향한다. 애플리케이션은 main이나 객체가 생성되는 과정을 모른다. 애플리케이션은 모든 객..