서론 스프링 시큐리티 볼 때마다 이해하는데 시간 엄청 들이고 넘겼는데, 다시 만나면 제자리다...ㅠ 이번에 프로젝트 샘플코드를 복습하면서 블로그에 정리하려 한다. Session HTTP의 기본적인 상태는 Stateless(무상태), 즉 아무 정보도 저장하지 않는다. request를 같은 사용자가 하더라도, 할 때마다 누가 누군지 모른다는 것이다. 하지만 실제로는 대부분의 웹사이트가 그렇게 작동하지 않는다. 로그인하면 한동안 로그인이 유지되어 있고, 장바구니 같이 회원이 누군지 알아야만 서비스 할 수 있는 기능도 있다. 이를 위해 보통 로그인시 서버 세션에 회원의 정보를 저장해놓고, 요청과 응답에 회원 기본키를 포함시켜 회원을 구분한다. 하지만 이 방법은 서버의 자원을 사용하기 때문에 접속자가 많을 경우 ..
서론 최근에 Entity 모델의 속성의 성격을 잘 생각해보고 불변해야 하는 것들은 final로 선언해 명확하게 하라는 코드리뷰를 받았다. 한번 생성되면 변하면 안되는 것들, 이 속성 없이 생성되면 안되는 것들은 추후에 변경돼 에러를 발생시킬 위험이 있고 규모가 커지면 추적하기 어렵다는 것이 이유였다. 오... final! 간단하군! 했는데 여러 문제에 봉착했다. 테스트 코드 작성의 어려움, 객체 변환에 어려움. Builder패턴... 여러가지로 전체적인 코드스타일이 변경되어야 했다. 아무튼, 여러 문제점 중에 여기서 말할 것은 객체 매핑이다. final로 선언된 속성이 있으면 기본생성자는 만들 수 없고 또한 setter 함수도 작성 불가능하다. 그런데 Spring Controller에서 자동으로 객체 매..
평소에 valueOf를 많이 썼는데 valueOf는 예외에 안전하지 않은 함수라서 org.apache.commons.lang3의 toLong을 사용하라는 코드 리뷰를 받았다. 무슨 차이가 있는 걸까? 형변환 함수 자바에서 형변환 할 수 있는 함수는 parse와 valueOf가 있다. parse는 원시형으로 타입을 반환하고 valueOf는 이를 wrap 한 클래스형으로 반환한다. long a = Long.parseLong(1); Long A = Long.valueOf(1); 이러한 형식의 문제점은 변환하려는 값에 문자가 올 경우 예외를 던진다는 것이다. 물론 그럴 가능성은 적겠지만, 안정적인 프로그램을 만들려면 사용자가 넣을 수 있는 값을 모두 고려해야 한다. Long.parseLong("99", 8) /..
서론 Spring MVC를 사용할 때는 DAO를 데이터베이스를 연결하는 객체로 생각하고 여기에 SQL문을 다 넣었었다. JPA를 배우고 난 뒤에 JpaRepository를 구현하면서 DAO는 자연스럽게 Repository로 생각하고 넘겼었다. 그러다 이 둘의 차이를 묻는 질문 글을 발견했고 그 답변의 내용이 상당히 어려웠다. 조금이나마 이해한 것을 번역하면서 글로 정리하지 않으면 다 잊어버릴까 봐 이렇게 글로 나마 정리한다. 내가 이해한 것을 토대로 작성하기 때문에 틀린 내용이 많을 수도 있다. 이 글은 답변 글 번역에 단순히 내 생각을 덧붙인 글로 나는 명확한 차이를 모르겠다. #1 DAO는 data persistence의 추상화다. Repository는 a collection of objects의 추..
※ SpringBoot를 활용한 REST 개발 공부 중, HTTP RequestBody 유효성 검사에 관한 내용을 정리한 자료입니다. @Test @DisplayName("username 없이, POST 회원가입 , 400 badRequest") public void post_whenUsernameIsNull_receiveBadRequest() { User user = TestUtil.createValidUser(); user.setUsername(null); ResponseEntity response = postUser(user, Object.class); assertThat(response.getStatusCode()).isEqualTo(HttpStatus.BAD_REQUEST); } 회원 Entity..
JS Module Export named export export const App = () => { ... } //import { App } from './App' default export const App = () => { ... }; export default App; // import App from './App' 둘 중 하나만 사용하는 것이 일반적이지만, 두 개 다 사용가능하다. 특히 Redux 테스트를 한다면 두 개 전부 사용하는 것이 유용하다. 둘 중 하나만 사용한다면 번거로운 점이 많아진다. export const App = (props) => { ... }; default export App; Redux 테스트 에러 Provider에 store를 생성해서 props로 줬는데 왜? con..
서론 최근에 학원에서 팀프로젝트를 하나 했는데, git branch에 익숙하지도 않고 시간에 쫓기다보니 그냥 master branch에 다 커밋했었다. 그러다보니 깃허브 커밋 이력이 엉망진창이다. 이번 기회에 글을 정리하며 깃허브 커밋 관리에 대해 좀 더 이해해보려 한다. Git Flow 예전에 branch를 공부하면서 얼핏 본 기억이 나는 그림이다. 배울 당시에도 좀 복잡했지만 실무에서는 이렇게 쓰겠구나하는 감이 와서 좋았었다. 위 그림만 봐도 어떻게 브랜치 형상관리가 이뤄지는지 알 수 있다. branch는 총 5개로 구분해서 관리한다. master : 제품으로 출시될 수 있는 브랜치 develop : 다음 출시 버전을 개발하는 브랜치 feature : 기능을 개발하는 브랜치 release : 이번 출..
Is offset pagination dead? Why cursor pagination is taking over Facebook’s developer page said it best: uxdesign.cc ※ 이 글은 위 글을 의역한 글입니다. ※ 제가 이해한 것을 토대로 약간 수정했습니다. 커서 기반 페이징이 가장 효율적인 방법이며, 가능한 항상 사용되어야 한다 -페이스북 개발자 그렇다면 페이징은 무엇일까? 페이징은 책 페이지처럼 데이터를 묶음으로 분리하는 과정이다. 페이징은 크게 2개로 나뉘는데, 둘 중 뭐가 좋을까? 한 번 알아보자. 오프셋 페이징 이 방법은 수십년동안 효과적으로 사용된 방법이다. OFFSET 값을 포함한 SQL 쿼리문을 동반한다. SELECT * FROM table ORDER B..
