요즘 결제팀에 소속되어 개발과 PO 역할을 함께 담당하고 있는데, PO는 처음이다 보니 관련 지식을 쌓고 싶어서 토스팀의 PO SESSION을 보게 되었다. 정말 정말 유익했고, (돈 내고 들어도 될 강의라는 댓글이 있었는데 나 또한 그렇게 느꼈다) 생각날 때마다 들여다보기 위해 정리한 것을 블로그에 남기려고 한다. 토스 리더가 말하는 PO가 꼭 알아야할 개념 PO가 알아야할 개념으로 Carrying Capacity를 이야기 해주셔서 처음으로 Carrying Capacity에 대해 알게 되었다. MAU를 들어보기만 했지 예측하는 방법에 대해서는 생각해보지 못했었는데 Carrying Capacity 개념으로 측정해볼 수 있다는 것을 알게 되었고, 해당 제품이 가지는 본질적인 체력이 얼마나 중요한지에 대해 ..
ObjectMapper로 JsonNode를 Class에 넣어주는 코드에서 UnrecognizedPropertyException 가 발생했다. mId라고 분명 클래스에 저장했는데, mid라고 인식하는 것 때문에 필드명 에러를 뱉어냈다. @JsonIgnoreProperties를 선언하면 무시하고 작업을 수행한다. 하지만, mId가 null로 들어가기 때문에 @JsonProperty를 써서 직접 mId로 지정 해주었다. @Getter @Setter @JsonIgnoreProperties(ignoreUnknown = true) public class PaymentInfoDTO { @JsonProperty("mId") String mId; }
JsonNode는 Jackson 라이브러리에서 제공하는 객체이다. 토스페이먼츠 결제 후 반환 값이 JsonNode로 반환되는데, 잘 몰라서 아래의 대참사를 만들어냈다 (허허) 찾아보니 JsonNode를 클래스 객체로 변환할 수 있었다. (jackson 라이브러리 추가되어 있어야 한다!) import com.fasterxml.jackson.core.JsonProcessingException; import com.fasterxml.jacdson.databind.JsonNode; import com.fasterxml.jackson.databind.ObjectMapper; // 클래스 생략 public PaymentInfoDTO JsonNodeToObject(successNode) { try { ObjectMa..
Nuxt는 디렉토리와 파일명 생성 구조에 따라 라우팅이 자동으로 되는 편리함이 있어서 간단한 프로젝트에는 따로 Express로 미들웨어를 구성할 필요가 없을 것 같다. 하지만 라우팅시, html, js 이전에 어떤 작업이 필요하다면 (Spring의 Controller와 같은? 이 비유가 맞는지 아직 확실하진 않지만) 아무튼 그 작업이 필요해서 Express를 사용하게 되었다. Nuxt에도 created, mounted등의 함수로 간편하게 구현할 수 있지만 html이 필요하지 않은 상황에 디렉토리와 파일을 생성하는 것보다 Express를 이용하면 더 깔끔할 것이라 생각이 들었다. ++ 추가로 Express를 먼저 공부한 후 Nuxt에 Express를 적용해 보았다. https://mean-ji.tistor..
여담으로 Express를 사용하게 된 계기: 토스페이먼츠의 결제창을 열고 결제를 완료 한 뒤, 승인하는 과정에서 successUrl과 failUrl이 중간 단계에 필요했다. Client가 Nuxt 프로젝트로 이루어져 있기 때문에 Url을 3000번 포트로 설정했고, 결제 승인 API 호출을 이 단계에서 해야했기 때문에 3000번과 결제 승인 API 사이에 미들웨어가 필요하여 Express를 사용하게 되었다. 기술지원 디스코드에서 내가 올린 질문은 아니지만 다른 분이 같은 질문을 하신 것에 대한 답변을 보고 참고하였다. Express 시작하기 Node.js를 위한 웹 애플리케이션 프레임워크. 웹 애플리케이션, API 개발을 위해 설계되었다. 설치 Node.js가 이미 설치되어있다고 가정한 상태에서 다음의 ..
깃 브랜치를 정말 아무렇게나 사용하고 있었는데 최근 깃 강의를 듣고 브랜치를 규칙에 따라 사용해보면 협업에 수월함이 있지 않을까 싶어 정리해보고 사이드 프로젝트에 먼저 적용해 보려고 한다. Git branch strategy 프로젝트 규모가 커지고 인원도 늘어나게 되면 하나의 레파지토리 내에 일정한 규칙이 존재해야 합니다. 저의 경우 소규모이지만 그래도 규칙은 필요한 것 같습니다 관리가 너무 어려워요ㅠ 오늘 공부한 깃 브랜치 관리 전략은 국내에서나 해외에서 통상적으로 사용하는 패턴이라고 합니다. 보통 Repository를 처음 만들고 나면 Branch 명은 Master로 생성이 됩니다. (인프런 깃 강의를 들어보니 요즘은 master보다는 main으로 사용하길 권장한다고 합니다.) 저는 main을 mas..
퇴근 하기 전에 커밋을 하고 가야하는데 가아끔 깜빡하고 그냥 집에 갈 때가 있다 그럴 때는 커밋을 아래와 같이 하면 된다고 한다 GIT_AUTHOR_DATE=2022-05-13T12:00:00 GIT_COMMITTER_DATE=2022-05-13T12:00:00 git commit -m "commit..!"
reset 옵션에 대해 이해하려면 깃의 3가지 공간에 대한 이해가 선행되어야 한다 깃의 3가지 공간은 아래와 같다 1. Working directory 2. Staging area 3. Repository 이렇게 세 가지 공간이 있는데 1번에서 file들을 저장하고 add 하면 2번으로 이동하고 2번에서 commit하면 3번으로 이동한다 파일을 수정하면 3번에서 다시 1번으로 돌아간다 git reset options --soft: repository에서 staging area로 이동 --mixed (default): repository에서 working directory로 이동 --hard: 수정사항 완전히 삭제 (repository에서 아예 세 가지 공간 중 어느 곳에도 속하지 않음) git check..
