기록장

처음에 악센트 없는 영어 문자로 127 가지 문자를 정했다. 이는 7bits에 저장할 수 있으며 이를 ASCII라고 불렀다. 그러나 그 이외의 문자들(여러 언어, 기호, 그림용 문자)를 128 - 255 에 각각 정하기 시작했다. 이렇게 다른 시스템들을 code page라고 한다. 더군다나 아시아의 알파벳은 천 개가 넘는다. byte를 string으로 바꾸는 건 쉽지만 반대로 하는 건 엄청 복잡한 일이었다. ASCII Unix가 만들어진 시기에 문자는 오로지 영어와 숫자뿐이었다. 이를 숫자 32부터 127까지 매긴 후 ASCII라고 한다. 이 문자들은 7bits 을 이용해 저장할 수 있었고, 1byte가 8 bit인 컴퓨터를 썼으므로 잉여 1 bit가 남게 되었다. 이 비트를 사람들은 각자의 목적으로 사..

https://www.inflearn.com/course/스프링부트-시큐리티/dashboard 인프런 강의를 듣고 정리한 글이다. JWT (Json Web Token) Json 객체. 디지털 서명이 되어 있음. HMAC 알고리즘 혹은 RSA 사용 구조 xxxxx.yyyyy.zzzzz x: header y: payload z: signature header { "alg" : "HS256", "typ" : "RSA" } 형태의 JSON을 Base64Url Encoding payload private claim: user id 같은 정보를 넣음 signature HMACSHA256(header + "." + payload, secret key) header + payload를 서버만 아는 secret key ..

inner class 로 인해 메모리 릭 발생 outer class의 작업이 끝났을 때 inner class의 outer class 객체 참조로 인해 메모리가 해제되지 않는다. → static을 붙이지 않은 inner class의 경우 outer class를 참조한다. ⇒ static inner class 를 선언

webclient retrieve vs exchangeretrieve : 바로 response body를 처리 가능.exchange상태 코드, 헤더 등 client response를 바로 전달해주어 세밀한 처리 가능.4xx, 5xx 응답코드에 대한 처리가 없어 개발자의 실수로 메모리 릭 발생 가능. 따라서 retrieve 를 권장webclient 로 nested object request body를 만드는 방법extra[second_field_name]대괄호 안에 넣으면 됨

Member Team --- --- id id team_id name username 객체와 테이블 연관관계 정리 객체는 참조로 연관관계를 맺는다 테이블은 외래키로 연관관계를 맺는다 객체는 양방향으로 연관관계를 설정할 수 없다. 양쪽에 설정한다고 해도 서로 다른 단방향 관계 2개인 것이다. 어노테이션 사용 연관관계 매핑 시 다중성을 나타내는 어노테이션 사용 필수 @ManyToOne, OneToMany, OneToOne attribute feature default value optional false 로 설정하면 연관된 엔티티가 항상 존재해야 한다. Inner Join true fetch 글로벌 페치 전략 설정 - @ManyToOne : EAGER @OneToMany : LAZY | | cascade |..

the simple way if check value is null object&.spouse&.name == object.spouse.name if object && object.spouse class 2, "name"=>"1"}, {"count"=>2, "hit"=>1, "name"=>"1"}, {"count"=>1, "hit"=>5, "name"=>"1"} ] # sort sorted_arr = arr.sort_by {|data| [data["count"], data["hit"]]} 결과 [{"count"=>1, "hit"=>5, "name"=>"1"}, {"count"=>2, "hit"=>1, "name"=>"1"}, {"count"=>2, "hit"=>2, "name"=>"1"}] it'..

index가 있어도 사용할 수 없는 경우 where에 부정이 있으면 index를 사용할 수 없다. 그래도 limit 절이 있으면 full join을 해도 문제가 없지만, 그게 아니라면 성능에 문제가 있을 수 있다 sort group by group by 를 하면 자동으로 group by 한 컬럼으로 정렬된다. 이로 인한 overhead를 막으려 한다면 order by null ORDER BY 에서 인덱스를 사용하지 못하는 경우 서로 다른 키를 ORDER BY에 사용하는 경우 키의 일부를 사용할 때 오름차순과 내림차순을 섞는 경우 ORDER BY 절에 사용된 키와 열을 가져오기 위해 사용된 키가 다른 경우 ORDER BY 에 키의 컬럼이 아닌 다른 표현을 사용했을 경우 (함수 사용) ORDER BY나 GR..

230315 : 2시간 진행. 포스트 상세 뷰포스트 상세인 만큼 각 파트마다 다르게 생각했던 점이 밝혀지고 논의할 점이 많았던 거 같아 유의미한 시간이었다.기획 의도도 알 수 있어서 이해도가 깊어진 듯 하다.시간을 살짝 줄여서 진행하는 게 더 집중력있게 진행되지 않을까 생각된다.230323 : 1시간 진행. 마무리하지못함. 크리에이터 페이지 상단이벤트 스토밍 전에 각 포스트잇의 단위와 진행 순서에 대해 리마인드하고 시작하는 것 좋을 것 같다.찾아보니 리드 모델이라고 특정 커맨드 후 사용자에게 보여지는 화면을 명시하여 비즈니스 플로우를 이해하는 데 도움을 줄 수 있다고 한다.논의가 길어지면 Issue 포스트잇으로 따로 빼고 진행하는 것이 좋을 것 같다

ruby 에서의 exception 처리 begin-rescue-else-ensure-end begin # 일반적인 코드 영역. exception 발생 시 rescue 로 넘어감 rescue A_ExceptionClass => a_var # A Exception 발생. 처리 rescue B_ExceptionClass => b_var # B Exception 발생. 처리 else # Exception이 raise 되지 않은 경우 ensure # Exception 발생 여부와 상관없이 무조건 실행됨 end

개요커머스 개발을 하다가 결제 부분에서 따닥 이슈를 만나서 해결하는 과정을 적어본다.😱 문제멤버십 구독을 할 때 유저가 n 번 누르면 요청이 n 번 들어와서 결제가 n번 된다.🤔 해결 방안1. 요청 시 클라이언트 헤더에 멱등 키를 받아서 여러 요청이 하나의 요청인지 아닌지 구분한다. (execute at most once)멱등 키는 서버에서 해당 구독 건에 대해 특정할 수 있는 key를 조합하여 사용하는 것으로 한다.멱등 키는 헤더에 설정. (IETF 표준)결제 요청 전에 DB에서 멱등 키를 확인하여 이미 저장이 되어 있으면 중복 요청으로 208 Already Reported 응답멱등 키와 요청한 endpoint 로 구별어디에 저장하지DB멱등 키 확인/생성하는 로직을 트랜잭션을 분리시켜서 구현한 다음..