프랑스얼음왕자

https://docs.google.com/document/d/1qZfqRSfVdI1ZlhEYOqrReSpMrHUaCGonC8L0jqE6tHk/edit

https://www.acmicpc.net/problem/1772 1772번: 정원 정리 첫째 줄에 n과 m이 주어진다. (1 7 -> 7 -> 8 -> 8-> 2-> 3-> 3 -> 4-> 9 -> 9 -> 10 -> 10 -> 11-> 11-> 4 -> 5 -> 5 -> 1 즉, 자기 노드로 들어올때 한 번, 자기 자식 싹다 돌고 나오면 다시 한번. 이렇게 되면 자기 자신이 다시 등장하는 구간은 싹다 자기 자식의 개수를 의미하게 된다. 1번 노드나 2번 노드를 보면 알수 있고 leaf노드들의 경우는 자기 자신 사이에는 아무런 노드가 오지 않는 것 또한 볼 수 있다. 이제 가지 자르기를 잘 생각해보면, A 노드와 A 노드의 자식들을 1)포함하거나 2) A노드는 포함하고 자식 들 중에서 잘라내거나 하는..

프론트에서 아무리 입력에 대한 예외 처리들을 잘 한다고 하더라도, 백엔드에서 검증하지 않으면 의미가 없다. 그렇기에 백에서는 많은 검증들을 거쳐야 한다. 주로 validation.constraints 어노테이션들을 (예를 들면 @Min, @NotNull 등등) 활용하여 검증한다. 이러한 검증에 대한 이야기는 다른 블로그에도 많고 어렵지 않은 내용이니 생략하기로 하고 내가 다룰 이야기는 중첩 객체와 Collection 객체 검증들에 대해 이야기 해볼까 한다. 0. 검증을 생략하는 문제 앞서, 검증 위치는 다양한 곳이 있지만 입력에 대한 검증 처리를 다룰 것이기 때문에 입력 DTO들에 대한 검증 처리에 대한 이야기이다. 일단 Collection Bean 검증에 대한 이야기부터 할까 한다. 아래와 같은 Con..

서버 배포를 앞두고 유지 보수를 위한 필수 정보인 로그를 파일로서 저장할 방법을 알아보았다. 로깅 레벨이나 설정 같은 것은 지난 번에 다루었으니 그보다 큰 틀인 파일 관리 특징들에 대해 다루겠다. 예를 들면 error 같은 로그는 따로 모은 다거나, 날짜 별로 로그를 모으게 끔 하고 일정 용량이 벗어나면 zip 파일로 묶게 하고 기준 날짜 지나면 자동 삭제되는 이러한 일련의 과정을 하는 법을 보여주겠다. 0. 기본 설정 resources 폴더 밑에 logback-local.properties 파일을 만들고 아래와 같은 코드를 입력해야 한다. log.config.path=/Users/yuseunghyeog/desktop log.config.filename=local_log 저장할 위치와 파일 이름이다. 만..

방학동안 프로젝트를 하면서 서버를 배포하게 되었다. 안드로이드가 통신용 서버랄까. ec2위에다가 자바, nginx, mysql... 뭐 이러한 것들을 설정 하고 rds 연결하는 방법도 있지만, 서버 배포 뿐만 아니라 꾸준히 유지 관리를 하기 위해서는 뭔가 편리한 방법이 필요했다. 흐름은 이렇다. jar 파일 올릴 곳. db 연결하기. route 53으로 domain 이름 설정 하기. 이 domain 이름으로 https 적용하기. 이 순서대로 시작하겠다. 1. Elastic Beanstalk 줄여서 EB아니면 EBS라고 한다. EBS의 모토는 개발자는 코드 작성만 하면 되고 배포, 확장, 관리를 모두 알아서 해주는 완전 관리형 시스템이다. 생성시 여러 설정으로 인스턴스 생성, 오토 스케일링, 로드 밸런싱 ..

이전 글처럼 간단한 오류와 간단하게 오류 페이지를 보여주는 것이 아닌 API 리턴해 주는 역할의 요청일 경우에는 json으로 응답을 해주어야 한다. 어떻게 해야할까? 으음.. 예를 들어 어떤 요청 파라미터 하나를 빼먹으면 null이 되니깐 이 경우 redirect를 해서 에러 json을 리턴하게 할까? 헐 굉장히 귀찮고 복잡하다.. 이렇게 하려면 막막해 보이지만, 스프링은 (당연하게도) 이런 상황에서 해결책을 제공해 준다. 0. BasicErrorController 지난 에러 페이지 글에서 /resources/templates 밑에 그냥 error디렉터리 만들고 error/4xx.html 같은 파일 하나 만들어 주면 알아서 에러 페이지를 핸들링 해주는 녀석이 API 예외처리에도 많은 역할을 해준다. 요 ..

우리가 의도한대로 사용자가 흐름을 타면서 움직이지 않는다. 그렇기 위해 테스트 코드를 정말 잘 짜야 한다고 하지요. 아무튼 결국 우리는 모든 예외 사항을 예측해야하고 예외 사항이 났다고 해도 사용자에게 불쾌한 경험을 하지 않도록 최선을 다해야 한다. 그렇게 예외 처리에 대한 다양한 도구들이 스프링에서 제공 되었다. 오류에도 크게 두 종류가 있는데, 예외 페이지를 띄우는 MVC역할을 할 경우와 API 리턴으로 예외사항이 생겼다는 JSON을 전달하거나. 일단 예외 페이지에 관련된 이야기를 하겠다. 1. 오류 처리 흐름 예외사항 발생 시의 흐름을 이야기해보자. try-catch가 없는 상태에서 예외가 터져버리면 서블릿 밖으로 예외가 던져진다. 이 순서대로 예외 사항이 올라간다. 예외사항 발생 시 WAS는 깊은..

굉장히 간단한 개념이고 코드도 간결하지만 잘만 사용하면 API 호출이던 MVC이던 꽤나 유용하게 사용할 수 있을 거 같아서 정리해보아요이이. 1. 타입 컨버터 요녀석이 무엇이냐. 간단하게 아래 코드를 보자. @GetMapping("/hello-v2") public String helloV2(@RequestParam Integer data){ System.out.println("data = " + data); return "ok"; } 위와 같은 코드에서 data의 타입이 Integer 일 수 있는 이유는 스프링에서 자체적으로 아래와 같은 역할을 해주기 때문이다. @GetMapping("/hello-v1") public String helloV1(HttpServletRequest request){ Stri..

자 잘 생각해보면, 로그인 기능은 구현하였지만, 각 컨트롤러마다 해당 로그인 사용자에 대한 정보를 얻어오거나 애초에 로그인이 안되어 있다면 접근 불가하게 하도록 같은 코드를 싸그리 다 복붙 해야할까? 잘 아시다시피 스프링은 이런 미친 짓을 가만히 두고 볼 일이 없다. 물론 AOP라는 방식이 존재한다. 하지만 난 이거 아직 공부를 안한 것도 있고 필터와 인터셉터 방식이 물론 AOP 보다 기능이 덜 하지만 메서드 실행 이전에 서블릿 단위에서 실행되어서 compact 한 느낌이랄까. 아무튼 진행해 보겠다. 1. 공통점과 차이점 가장 큰 차이점으로는... HTTP 요청 ->WAS-> 필터1 -> 필터2 -> 필터3 -> 서블릿(디스페처 서블릿) -> 스프링 인터셉터1 -> 인터셉터 2 -> 컨트롤러 위와 같이 ..

지난번에 카카오 Id를 얻어 왔고 이 값으로 세션 방식으로 로그인을 구현해보자~~ 1. 사전 배경 우리는 응답 HTTP에 Set-Cookie헤더를 이용하여 클라이언트의 쿠키 저장소에 이름-값 쌍을 저장하게 강제한다. 클라이언트는 요청을 보낼 때마다 Cookie: 라는 헤더에 그 값을 함께 보낸다. 쿠키 저장소란, 클라이언트의 어플리케이션 레벨에 {name:value}형식으로 저장되어 있다고 보면 된다. 이것을 로그인에 사용하는데, 사용자가 인증이 되면, 사용자에게 아이디 대신 임의의 값(카카오 로그인에서 code 값 같은 거. SessionId라고도 부름)을 Set-Cookie를 통해 보내고, 세션 저장소에 이 임의의 값(asoidnon123)과 id 값(2113) 매핑을 시켜놓은 테이블에 저장한다. 그..