TL;DR Aurora MySQL db를 업데이트하는 2가지 방법을 소개 2가지 방법 중 좋다고 생각한 방법과 이유를 소개 왜 와이 Aurora DB 2점대의 depreacation이슈 MySQL 5.7의 지원 종료와 함께 몇일 전이었습니다. MySQL 5.7버전이 정식 지원 종료된다는 소식을 들은게… 이에 AWS에서는 AuroraDB 2점대를 3점대로 업그레이드 하라는 안내를 주었습니다. 그걸 이제서야 본 것이죠. 부랴 부랴 문서를 찾아 읽기 시작했습니다. 다행이도 문서는 매우 잘 정리가 되어있었고, 한글로 봐도 될 정도의 번역으로 만들어져 있었습니다. 이 글은 그 문서들을 읽고 내린 의견과 문서를 약간 정리한 내용을 소개하는 글입니다. 당연하게도 잘못된 지식을 바탕으로 내린 결정일 수 있으니, 너그러히 알려주시면 감사드리겠스니다. ...

TL;DR Spring에서 RestAssured를 이용해 인수 테스트를 작성하는 방법 학습 Spring에 대한 이해의 한계를 맛봄 JPA를 사용해봄 NextStep ATDD with Spring 왜 와이 80만원 주고 강의를 샀습니다. 최근 JAVA를 학습하겠다고 다짐하여 Spring에 대한 학습을 다시 시작했습니다. 혼자 학습하고자 고군분투했지만 남는게 많이 없다고 느끼는 요즘이었습니다. 그런 그때, 과거에 결제만 했었던 NextStep에서 메일을 한통 받았습니다. ATDD with Spring 강의를 시작한다는 내용이었습니다. 강의 비용은 80만원이었지만 저는 지를 수 밖에 없었습니다. 강의 전반에 걸쳐 코드리뷰를 받을 수 있다는 점이 검토가 필요했던 제게 너무나도 매력적인 부분이었기 때문입니다. ...

TL;DR 외우지는 못했다. 읽어볼법 하다. 능동적인 태도가 필요하다. 자바의 신을 읽게 된 계기 F-lab의 준비 도서 본인은 Javascript를 주언어로 사용하는 개발자입니다. 회사 환경에서 성장하고 있지 않다는 생각이 많이 들어서 F-lab Java 백엔드 과정을 신청했습니다. 해당 과정의 사전 과제 중 하나가 ‘Java의 신’을 읽기는 것이었습니다. 책의 첫인상 2권짜리 책은 합치면 생각보다 두꺼웠습니다. 하지만 인상과는 별개로 책의 시작은 그리 어렵지는 않았습니다. 제가 전공생이라서 그런 것인지, 책이 어렵지 않아서 그런 것인지는 잘 모르겠습니다. 책의 시작 부분을 빠르게 넘길 수 있었고, 읽는데 어려움은 크게 없었습니다. ...

TL;DR 채팅 예제를 만들어 본 후기 문서, 코드? 흥미 driven 개발. 채팅 예제 만들기 2 기대 요망. 채팅 예제 만들기 왜 와이 실력에 대한 고민을 하면서 저는 스스로를 반쪽짜리라고 생각해 왔습니다. 경험도, 지식도 부족한 반쪽짜리 개발자. 그래서 고민을 오래한 것 같습니다. 과연 잘하는 개발자란 무엇인가. 업무적으로 장애를 만나 수정할 기회가 없는 상황이라면, 성장하기 위해 무엇을 할 수 있을까. 고민 끝에 나온 결과는 ‘하고 싶은 걸, 하고 있을 때, 하고 싶은 형식으로 개발할 수 있는 능력’을 갖춰야 한다고 생각하게 되었습니다. ...

ref: https://www.postgresql.org/docs/current/ddl-rowsecurity.html Row Level Security 메타 정의 boolean을 리턴하는 query를 테이블의 row에 접근할 때 호출해 접근 권한을 확인하는 보안 방법 정의된 policy를 따름. 동작 optimizer의 optimization등의 leak proof fucntion 동작 RLS 확인 주어진 query 수행 활성화 ALTER TABLE ... ENABLE ROW LEVEL SECURITY; table owner등 bypassRLS 조건인 경우, RLS 확인을 강제하고 싶은 경우 아래 command 사용 ALTER TABLE ... FORCE ROW LEVEL SECURITY 활성화 여부는 policy 삭제와 관계 없음 table의 RLS가 disabled라도 policy는 편집 가능 고려 사항 performance row 접근시 마다 확인하기 때문에 영향을 줄 수 있다. indexing, sub query 등으로 속도 개선할 수 있다. race condition view 권한의 업데이트 과정에서 오류가 발생할 수 있다. a, b 유저 존재 a의 권한레벨은 2, b 의 권한레벨이 4 b가 a의 권한레벨을 1로 낮추고 권한 레벨 2의 정보를 생성한다. 이와 동시에 a가 조회할 경우 b가 작성한 내용을 열람할 가능성이 있다. 해결 방안 update시에 ACCESS EXCLUSIVE LOCK 걸기 등 Policy Syntax 분석 syntax 1 2 3 4 5 6 7 CREATE POLICY name ON table_name [ AS { PERMISSIVE | RESTRICTIVE } ] [ FOR { ALL | SELECT | INSERT | UPDATE | DELETE } ] [ TO { role_name | PUBLIC | CURRENT_ROLE | CURRENT_USER | SESSION_USER } [, ...] ] [ USING ( using_expression ) ] [ WITH CHECK ( check_expression ) ] as [Permissive vs Restrictive] Permissive (default) OR 조건으로 조건 확인 Restrictive AND 조건으로 조건 확인 to [Role] authenticated 등 대상 user 조건의 확인 public으로 할 경우, 모든 유저 대상으로 query 실행 ` RLS 먼저 실행 후 모든 유저 대상으로 실행 Using === WITH CHECK 동일한 역할을 하는 이름 boolean 값을 리턴해 주면 됨. false가 아니면 true로 처리하는 듯 함.