일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 달팽이
- 메모이제이션
- 스택
- 게이트웨이
- 이분 매칭
- docker-compose
- Zuul
- ZuulFilter
- spring cloud
- 서비스 디스커버리
- 구현
- spring boot
- 이분 탐색
- 도커
- 백트래킹
- 유레카
- 다익스트라
- 트리
- Logback
- 스프링 시큐리티
- Gradle
- 플로이드 와샬
- 비트마스킹
- 완전 탐색
- 주울
- BFS
- 구간 트리
- dp
- Spring Cloud Config
- Java
- Today
- Total
목록분류 전체보기 (387)
Hello, Freakin world!
@ControllerAdvice란? 간단하게 말하자면 @ExceptionHandler, @ModelAttribute, @InitBinder 가 적용된 메서드들을 AOP를 적용해 컨트롤러 단에 적용하기 위해 고안된 애너테이션 입니다. @RestControllerAdvice란? @ResponseBody + @ControllerAdvice => @RestControllerAdvice 우선 HelloException 이라는 간단한 예외를 만듭니다. public class HelloException extends RuntimeException{ public HelloException() { super("Hello, Exception!"); } } 다음은 컨트롤러를 만들고 해당 메서드에서 위의 예외를 던지게 합니다..
레퍼런스들을 읽어보고 어떤 걸로 하이퍼미디어를 구현할지 알아보는데 3일? 정도 걸렸다. 하루 대부분 영어 문서들을 거북이처럼 읽어가며 보냈기 때문에 체감상 훨씬 오래걸린 듯한 기분이다. 내가 찾아본 바로 RESTful API를 구현하기 위해서 3가지 방법이 있다. 1. 직접 JSON 응답 객체를 작성한다. 2. Spring HATEOAS 를 이용한다. 3. Spring Data REST 를 이용한다. 1,2번과 3번을 두 그룹으로 나눠서 보자. 내가 느끼기엔 서로 느낌이 좀 달랐다. 1번은 너무너무너무너무 거추장스럽고 고생스럽다. 2번은 1번을 하지 않도록 유틸 클래스와 메서드를 제공한다. 2번은 딱히 어떤 계층에 의존하지 않는다. 보통 컨트롤러 계층에서 작성하지만 굳이 다른 계층에서 할려고 한다면 객체..
내게 REST api는 그냥 http 통신 응답 바디에 단순하게 json 객체같은 형태로 데이터를 반환하는 것. (쉽게 말하자면 그냥 스프링 @RestController 핸들러 메서드에서 객체를 반환하는 것과 같은) 그리고 url을 통해서 리소스를 정의하는 관례들, 그리고 Http method를 이용해서 리소스를 가공하는. 이런 식으로만 알고 있었다. 하지만 뭔가 위화감이 느껴졌다. '고작 이런게 REST라고?' 의심하기 시작하니 뭔가 이상한 부분이 느껴졌다. URL 관례나 응답 데이터 포맷, Http method에 관한 부분에 대한 부분은 그냥 일반적인 HTTP를 기반으로한 규칙 정도로 느껴졌기 때문이다. 정말 그것 뿐이라면 REST라는 이름을 붙이고 떼어내 아키텍쳐로 분리하기도 민망하지 않은가? 내가..
생각해보니 RoleType 이라는 속성도 의미가 없었다. 비회원은 User 엔티티 속성이 모두 null이여야 한다. 비회원, 회원, 관리자를 단순히 하나의 필드로 구분할게 아니라 완전히 다른 개체로 분리해야 하는건 아닌가라는 생각이 들었다. 그래서 일단 지금은 User -> Customer 로 바꾸고 RoleType 속성은 삭제하자. 비회원과 관리자는 일단 미뤄둔다. import ... @Getter @ToString @NoArgsConstructor @Entity @EntityListeners(value = AuditingEntityListener.class) public class Customer { @Id @GeneratedValue(strategy = GenerationType.SEQUENCE) ..
이전 글에서 설계한 명세대로 User 엔티티를 작성해보자. User package com.springboot.myshop.domain.user; import lombok.Builder; import lombok.Getter; import lombok.NoArgsConstructor; import javax.persistence.*; import java.time.LocalDateTime; @Getter @NoArgsConstructor @Entity public class User { @Id @GeneratedValue(strategy = GenerationType.SEQUENCE) @Column(name = "USER_ID") private Long id; @Column(nullable = false,..
시작하는 단계라 대략적인 도메인을 나누고 수량 관계만 표현했다. 이제 회원 도메인을 좀 더 다듬어보자. 회원 필요한 기능1. 회원 등록2. 회원 정보 조회3. 회원 정보 수정4. 회원 탈퇴5. 인증 (관리자, 비회원, 멤버를 구분해야 한다) 1~4 는 결국 간단한 CRUD다.5번도 일단은 간단하게 이메일, 비밀번호를 받아 데이터베이스에서 비교하는 식으로 구현할 계획. (추후에 OAuth, Spring Security를 다시 적용할 예정) 위를 바탕으로 회원 객체 속성들을 나열해 보자. 회원 클래스 속성- id : Long = JPA 식별자- email : String - password : String- address : Address - createdDate : LocalDatetime - modifi..
이틀 전에 뛰었던 종아리 근육통이 뛰기 전까지 조금 남아있었다. 요즘은 격일로 뛰기 때문에 보통 다음 뛰는 날까지는 근육통이 회복됐는데 이번은 예외인듯. 회복 속도가 느려진걸까? 아니면 그전 달리기 강도가 너무 높았던걸까? 아무튼 통증을 참으며 달리기 시작. 여전히 포어풋 착지법을 적용해 달렸다. 텐션이 너무 처지지는 않게 어느 정도의 속도는 유지하면서 달렸다. 완주하고 나니 종아리가 당기는게 느껴진다. 확실히 무릎에 무리는 덜 가지만 하중이 종아리에 엄청나게 걸린다. 덕분에 종아리에 알이 조금씩 커지는 듯한 느낌. 나쁘지 않다.
보통 일지는 다음날 일을 시작하기 전에 쓰곤 했는데 깜박해버렸다. 이틀 뒤에 쓰려고하니 가물가물하네 꽤 빠르게 달렸던 날이었다. 달릴 때 다리를 약간 들어 올린다는 느낌으로 뛰니 속도를 더 경쾌하게 낼 수 있었다. 그냥 들어올린다는 느낌이 아니라... 발을 딛는 순간 그 반대로 약간은 의식적으로 다리를 올리는 건데 말로 설명하려니 복잡하다. 여튼 저렇게 달리면 약간 불편한 느낌이 들긴 한다. 안써본 근육이라서 그런듯. 약간은 새로운 발견이었다. 하지만 이 방식은 다리 근육이 많이 사용되는 느낌인데, 일단 다음에 한번 더 뛰어보고 다시 생각해보자.
확실히 무릎에 무리가 덜 간다. 종아리 쪽도 단련이 된건지, 그렇게 뭉치거나 하지 않는다.