[기록결산] 애쓴 것은 언젠가 정산된다.
[기록결산] 애쓴 것은 언젠가 정산된다.
생애 첫 연말정산을 끝내고, 1월도 막바지라는 생각에 '기록결산'이란걸 해보려고 한다.
딱 드는 생각은 뭐다? 월말결산을 월마다 해야한다는 뜻이지요 ..
바로 회고를 습관화해보고자 월마다 성찰과 반성과 반영을 동시에 하자! 라는 목표 하나로 24년을 기록해보려고 한다.
물론 더 꼼꼼하고 자세히 적는 것이 물론 독자나 미래의 나에게 더욱 좋을 것이다.
하지만 완벽주의의 탈피를 쓴 필자는 이 일을 1년 뒤로 미룰 것이기 때문에 완벽하지 않아도 기록하고자 한다.
24년 1월 3일
import get from "lodash/get"; / lodash 알아보기
24년 1월 4 ~ 5일
중단 배포와 관련 QA를 쳐내다 .... !
24년 1월 8일
ga gtm
gym = google tag manager
태그를 걸어놓으면 이벤트를 줄 수 있음
custom event
요구사항 user flow
메인 페이지에서 어디서 이탈하는지
userId
Tag data layer에서 읽어와서 ~
gym custom event recommended
최초결제만 쏘고 / 재결제는 백엔드에서 쏘면 됨
24년 1월 9일
수정 후, 테스트는 꼭 하고 push 하자.
pg사 콜백 대응
포트원에서 결제가 일어났거나 취소되거나 하면 eggnog를 찌른다.
그걸 받아서 구독을 취소한다던지 한다…
record web에서 안 하고 모종의 이유로 그냥 결제가 바뀌었을 때
예를 들어 고객이 다른 루트로 환불을 한다거나 했을 때 그거에 반응해서
구독과 결제 db에 반영한다 .. 는 내용!
24년 1월 10일
docker images: 이미지 확인 가능
docker images prune: 안 쓰는 이미지 친구들을 지워줌. 하지만, 띄운 상태에서 해야지 안 쓰는 애들만 지워진다.
24년 1월 11일
해지 예약 : unsubscribe
환불 : cancelSubscription
subscription.trial == true : 무료체험권
subscription.subscriptionType.trial == true : 기프트
master 브랜치와 release 브랜치의 내용이 다른 것 같다면
release로 checkout 받고 git diff master 로 확인해보자. 결과가 없다면 다른 점이 없는 것.
hotfix를 해야하는 경우라면 release 브랜치에서 새로운 브랜치를 따고 작업을 한다.
모든 작업이 끝난 후, 브랜치를 삭제하지 않고 master를 rebase 받고 pr을 다시 올린 뒤 마스터에 머지한다.
git checkout master -> git pull —prune -> git checkout pil-100 ->
git rebase master -> git push origin pil-100 -> master에 머지 !
vscode내에서 터미널이 잘 안 먹거나 좌측 git source control이 잘 안 된다 싶으면 껐다 키자. (이유없이 고생말고)
‘lazy로 정의된 association 객체들을 한 번의 쿼리로 읽어오는 기능 -> jpa에 흔한 n+1 문제를 해결해준다.’
private EntityGraph<Payment> getListEntityGraph() {
EntityGraph<Payment> graph = entityGraphFactory.getEntityGraph(Payment.class,
"paymentMethod", "organization", "refunds");
graph.addSubgraph("organization").addAttributeNodes("owner");
return graph;
}
생각보다 에네르기파 코드를 만든다. 필요없는 else는 쓰지 않도록 하자.
why? 에네르기파를 쓸수록 가독성은 낮아지기 떄문이다.
if (예약중이면) return 예약중 컴포;
if (체험이면) return null;
return 기본값
alpha에서 확인해보고 beta / real 배포하자.
24년 1월 12일
spring eureka 가 로드 밸런싱도 해주는거같아.
our gateway : session 에 대한 관리를 하고 있음.
eureka를 쓰려면 spring project를 만들어야해.
our registry: eureka server
lb: load balance 약어
ALB
Router53 == AWS
eureka는 service discovery도 해준다.
login session redis(session)
oauth가 token 발급
eggnog -> ServiceToken
redis distributed lock (redis -> key value 저장소)
redis ttl (~초) 이 원래 있음
(-> 알아볼 수 있는가 ..? 그 때 그 때 정리하자 ...)
24년 1월 16일
gopass 관련 에러 -> 1월 17일 gopass 설명
리액트에서 컴포넌트는 다양한 역할을 한다.
어떤 컴포넌트는 UI를 표현하고, 어떤 컴포넌트는 동작하는 로직을 담고 있을 수 있다.
‘관심사의 분리’가 무엇인가?
관심사의 분리란 복잡한 코드를 비슷한 기능을 하는 코드끼리 별도로 관리하는 것을 말한다.
그럼 컴포넌트를 분리하는 기준은 무엇인가?
컴포넌트를 분리하는 기준은 프로젝트마다 기준점을 어디에 잡느냐에 따라 다양한 분리 기준이 존재한다.
1. view와 로직을 분리하는 경우도 있고
2. state에 따라서 분리하는 경우도 있다.
컴포넌트 각자가 store를 가진다. -> *(님이 말씀하신 내용)
지금은 Pane이라는 큰 컴포넌트에서 각자 필요로하는 여러 필요한 컴포넌트들(Button, Select 등 ..)이 묶여있는 형태이고
이 Pane에서 관련 필요한 정보들을 저장하는 Store로 묶여있어 어느 정도의 선후배경지식을 가지고 있어야 수정이 가능하다.
예를 들면, LibraryTextUrlPane이 LibraryTextUrlStroe를 가지고 있다.
서버로부터 필요한 데이터는 LibraryTextUrlService에서 가져와서 Store에 이를 저장하고 다시 Pane이 가져오는 흐름이다.
24년 1월 17일
component <=> store <=> service (transport layer)
component <-> service (에러처리) <-> transport layer
store 에서는 저장과 조회만
store를 관리하는 훅이 나와야해 (singleton으로)
fabric.js
“It takes care of canvas state and rendering, and lets us work with “objects” directly.”
"add" rectangle onto canvas
“With native methods, we operate on context “
“In Fabric, we operate on objects — instantiate them, change their properties, and add them to canvas. “
You can see that these objects are first-class citizens in Fabric land.
Notice a very important difference. With Fabric, we no longer need to erase the content before attempting to “modify” any content.
We still work with objects, simply changing their properties, and then re-render canvas to get a “fresh picture”.
24년 1월 25일
간단하게 얘기하자면 React 에서 fabric.js canvas 인스턴스에 대한 참조를 저장하기 위해서이다.
1. Preserving State Across Renders (렌더간 상태 보존)
react에서 컴포넌트가 다시 렌더링될 때마다 지역 변수는 다시 초기화 된다. useRef를 사용하지 않고 컴포넌트 함수 내에서 fabric.js canvas 인스턴스를 만들면 컴포넌트가 다시 렌더링될 때마다 계속 재생성된다.
2. Avoiding Unnecessary Instantiations (불필요한 인스턴스화 피하기)
fabric.js canvas 인스턴스를 만드는 것은 비용이 많이 드는 작업이다.
캔버스 인스턴스를 매 렌더링마다 다시 생성하면 성능 문제가 발생할 수 있다. ref를 사용하면 컴포넌트가 마운트될 때 캔버스 인스턴스가 한 번만 생성되고 이후의 렌더링에서 재사용된다.
fabricRef는 useRef(null)로 초기화되며 fabric.js 캔버스 인스턴스에 대한 참조를 보유한다.(fabricRef.current)
캔버스 인스턴스는 컴포넌트가 마운트될 때 (useEffect with an empty dependency array) 생성되며 재생성되지 않고 렌더링 간에 지속된다.
24년 1월 30일
mysql 인덱스 생성
CREATE INDEX 인덱스명 ON 스키마.테이블명 (컬럼명)
CREATE INDEX idx_test_yn ON eggnog.organizations (test_yn)
In React, the ‘nativeEvent’ property is a reference to the underlying browser’s native event that the synthetic React event wraps.
nativeEvent 는 React에서 합성 이벤트로 감싸진 원본 브라우저 이벤트에 대한 참조이다.
It provides access to the browser’s original event object, allowing you to access properties and methods that are not available in the synthetic React event.
이 속성은 브라우저의 원래 이벤트 객체에 액세스할 수 있게 하며, 합성 React 이벤트에서 사용할 수 없는 속성 및 메서드에 엑세스할 수 있도로 합니다.
정말 날 것 그대로의 메모라 어디 숨고 싶지만 이를 계기로 잘 적길 바란다.
첫째 주는 배포와 QA로 인해 비즈니스 로직 관련 기록이 많았고, 공개하기 좀 그런 메모는 삭제하였다 ..ㅎ
이후엔 꽤 일하는 태도와 되새길만한 점을 적어놓았다. (사실 같은 실수를 반복하기 싫은 과거의 나의 노력..)
사실 제대로 알지 못하는 부분에 대한 기록으로 시작했던거라 모든 내용이 개발로 귀속되진 않지만
개발 중 몰랐거나 헷갈렸던 부분을 기록하고자 했기에 잘 정리할 필요도 있을 것 같다.
1. 정해진 시간에 글을 써보자.
어디서 주워들었는지는 모르겠지만, 정해진 시간에 글을 쓰는 습관을 들이는 (유명한) 개발자 분이 있다고 한다. (그도 노력하는데 나도)
2. 나중은 없다. 그 때 그 때 잘 정리하자.
그리고 이렇게 한 달(?)동안의 메모를 보며 느낀 점은 완벽한 글은 아니여도 나중에 알아볼 수 있을 글을 쓰는 연습을 해야할 것 같다.
메모와 기록 그 중간을 잘 찾아봐야겠다.
3. 몰랐던건 다시 잘 찾아보자.
기록만 해놓고 찾아보지 않으면 무소용이다. 잘 정리해서 내 것으로 만들어야겠다.
4. 기록결산을 어떻게 잘 할 수 있는지에 대한 목차를 생각해보자.
기록의 뼈대를 만들어봐야겠다.
요즘 맘에 간직하고 있는 말이 있다.
"애쓴 것은 언젠가 정산된다."
"헤맨 만큼 내 땅이 된다"
월마다의 기록결산이 잘 되어 경험이라는 큰 자산을 만들고 싶다.
