How to be awesome

SQL 출력문을 반드시 확인하자. JPA에 익숙하지 않을때는 아무래도 구현하는 것에 더 집중하면서 실제 SQL 쿼리문이 어떤식으로 나오게 되는지 유심히 보지 못한 것이 사실이다. 이번 프로젝트에는 꼼꼼히 볼려고 노력해봤는데 SQL문을 확인해면 크게 2가지 문제가 있었다. 문제 1. 불필요한 Outer Join (optional 속성을 반드시 명시하자) 관계를 맞는 엔티티간의 관계가 반드시 존재하는지, 혹은 선택적인지에 따라 실제 두 테이블(도메인)을 조인하는 전략이 달라지는데, 만약 관계가 반드시 존재한다면 (= 테이블상의 FK가 반드시 존재한다면), optional 속성을 통해서 이를 명시해야한다. 그렇지 않다면 null인 경우도 대비해야 하기 떄문에 outer join이 발생한다. (+ 추가적으로 @..

책 목차 트리구조로 구현하기 책 목차는 하위 목차와 상위 목차가 있기 때문에, 이를 트리구조로 보여준다면 좀 더 직관적인 UI를 만들 수 있다. 근데, 트리구조 구현을 하는 과정이 생각보다 쉽지 않았다. (정확히는 경험이 없기 때문에 어려웠다.) 트리구조를 구현하기 위해서는 재귀적인 과정으로 자신의 하위 목차들을 불러와야 했다. 알고리즘 문제 이외에 처음으로 재귀를 써본 경험이었다. 실무에서 재귀구조를 잘 안쓴다고 하던데 좋은 경험이었다. 다행히 책 목차의 도메인 구조가 셀프참조로 설계가 되어있어서 설계도 잘 진행 되었던 것 같아 기분이 좋았다. 타임리프에서 트리 구조를 하기 위해서 다음과 같이 작성하였다. . . .(생략) . . . 핵심이 되는 곳은 강조된 곳이다. bookContentTree라는 이..

JPA 그래프 탐색 JPA를 사용하기 위해서 만든 도메인 객체 A,B가 있다고 가정해보자. A객체가 B객체에 대한 방향을 갖는다고 할 때, A객체는 B객체의 그래프 탐색이 가능하다. (쉽게 말하면 A.getB를 이용해서 B정보를 가져 올 수 있다는 점이다.) 근데 엄청난 착각을 하고 있었다. A객체는 B객체를 Lazy하게 가져온다고 했을 때, 그래프 탐색이 가능한 범위의 레이어는 컨트롤러단 까지라고 생각했다. 뷰단에서는 막연하게 응답 이후에 처리 된다고 생각했는데, 스프링MVC 구조를 떠올리지 못했다. 위의 사진은 스프링 MVC의 구조를 잘 나타내고 있다. 요청부터 응답까지 어떤 과정으로 되어 있는지 도식화 해두었다. A객체가 B객체의 그래프 탐색이 가능한 범위는 위의 사진에 나와있는 모든 단계에서 가능..

로그인 여부 & 권한 여부 확인하기 로그인 하지 않은 사용자에게 '로그인' 메뉴가 노출되지만, 로그인 한 사용자에게는 '로그인' 메뉴가 사라지고, 혹은 관리자 권한을 가진 유저에게만 관리자페이지로 가는 메뉴를 노출해야 하는 일은 프론트 구현 과정에서 필수적인 과정이다. 기존에는 세션을 이용하여서 직접 유저의 권한과 로그인 여부를 확인했었지만 스프링 시큐리티를 적용했기 때문에 이런 과정도 스프링 시큐리티를 이용하여서 진행해야 했다. 1. MAVEN 의존성 설정 기존에 타임리프를 사용하기 위한 의존성 이외에 추가적으로 아래와 같은 의존성을 설정해야 한다. org.thymeleaf.extras thymeleaf-extras-springsecurity5 3.0.4.RELEASE 2. SpringSecurityD..

이왕이면 다홍치마 백엔드 개발자들을 꿈꾸는 학생(?)들이 모여서 하는 프로젝트라고 하지만 프론트(뷰)단이 너무 못생기면 어디 내놓기가 많이 민망하다. 이런 문제를 쉽게 해결해 주는 것이 부트스트랩인데, 쉽게 생각하면 디자인을 무난하게 일정 수준의 품질로 나오게 할 수 있는 css의 모임? 이라고 볼 수 있다. 사실 이전 미니 게시판 프로젝트는 부트스트랩보다 좀 더 세련 되 보이는 semantic-ui를 사용 했었는데, 바로 적용 할 수 있는 테마가 적어서 부트스트랩으로 선회했다. 테마 고르기 테마를 고르는 기준은 심플하고 깔끔한 디자인 이였다. 아무리 좋은 테마라도 결국 다른 목적의 웹사이트로 바뀌기 위해서는 커스터마이징은 필수로 진행된다. 화려한 테마일 수록 커스터마이징이 힘들 것으로 예상될 것 같아 ..

책 목차 정렬하기 DB상에 저장된 책의 목차들을 사용자에게 보여주기 위해서는 아래와 같은 조건이 있다.목차는 상위 목차를 한개 가질 수 있다.목차는 하위 목차를 여러개 가질 수 있다.위와 같은 조건만 있다면 답글이 달리는 '계층형 게시판'을 구현 할 때 사용 한 알고리즘이면 충분했다. 하지만 책 목차와 게시판의 결정적인 차이점은 게시판은 글간의 위치가 수정되는 경우가 거의 없지만, 책 목차를 관리하는 관리자 입장에서 순서가 변경 될 수 도 있기 때문이다. 예를들어 한 목차가 다른 목차와 순서를 바뀌게 되면 그의 하위 목차들도 모두 따라가야 한다. (대신 순서를 바꾸는건 같은 depth의 목차만 바꿀 수 있도록 한다.) 이를 해결하기 위한 방법으로 3가지가 고려 되었다. 공통적으로 목차가 어느 수준의 목차..

Spring Security 로그인하여 세션에 정보를 저장하고, 유저 권한에 따른 URI 접근까지 Spring Security를 이용하면 간편하게 구현 할 수있다.. 라고 배웠지만, 공부하기가 너무 어렵다. 이런저런 예제를 따라해보기도 했고, Spring Boot와 Spring의 시큐리티 설정이 얼마나 다른지도 몰라 예제를 찾아보는 것도 힘들었다. 2일간 삽질하여 얼추 원하는 방향으로 구현 할 수 있었다. (막상 완성된 예제를 보니 아주 어렵지는 않았지만 삽질의 주된 원인은 어떤 곳이 문제인지 알 수가 없었기 때문이었다.) 시큐리티는 개발하면서 지속적으로 공부를 해봐야 정교하게 구현 할 수 있을 것 같다. 현재까지 구현한 시큐리티는 아래와 같다. WebSecurityConfigureAdapter WebS..

타임리프 Thymeleaf 이전에 게시판 프로젝트를 하면서 JSP를 주로 써왔지만, 요즘엔 JSP보다는 다른 템플릿 엔진들을 더 많이 쓴다는 말에 그중에 하나인 타임리프를 사용해보기로 했다. 사실 구현상에서 JSP에 불편함을 느낀 것은 아니었지만, 타임리프를 적용해보니 만족도가 꽤 높았다. 일단 HTML 사이에 JSP문법들이 생기는지 않아 HTML 태그가 더럽혀 지지 않고 훨씬 깔끔했다. 초기에 적응하는 시간만 지난다면 가독성도 높아졌다. 먼저 디자인 없이 기능상의 뷰를 구현해보고, 이후에 CSS를 적용할 때 이점은 다시 한번 느낄 수 있을 것 같다. //타임리프를 이용하여서 구현한 for문 - 별도의 태그선언 없이도 기존 태그 안에 속성처럼 작성이 가능하다. 삭제 AJAX 구현을 위한 fetch API..