일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- JPA
- 기술면접
- 소켓
- 소켓통신
- jwt토큰
- socket
- CS면접
- spring
- 테스트코드
- 스프링
- 스프링소켓통신
- cs지식
- 채팅구현
- MongoDB
- springboot
- 스프링시큐리티
- 단위테스트
- Security
- 반효경
- 자바
- Stomp
- java
- rabbitmq
- jwt
- 운영체제
- 스프링부트
- 자바문법
- OS
- Mock
- CS
- Today
- Total
목록Web (23)
Dev_Henry

상황현재 진행중인 프로젝트에서 사용자가 종료시간을 설정하여 과제를 생성할 수 있다.해당 종료시간이 되면 과제는 자동으로 종료상태가 돼야하기 때문에 스케줄링 처리가 필요했다. 기존 방식처음 구현한 방식은 @Scheduled 어노테이션을 활용하는 방법이었다.구글링을 통해 찾아봐도 스프링에서 스케줄링 처리를 하는 방법은 모두 해당 어노테이션을 사용하는 방법으로 설명한다. 하지만 여기에는 문제가 있었다.현재 요구사항은 사용자가 직접 종료시간을 설정해 과제를 생성하기 때문에, 스케줄링이 동작해야하는 시간이 고정되지 않았는데, @Scheduled로는 처리할 수 없었다. 간단하게 살펴보자면, 해당 어노테이션은 속성으로 스케줄링 시간을 설정할 수 있는데,fixedRate, fixedDelay 속성은 ms단위의 시간을 ..

최근 진행한 프로젝트는 '개인 경매 플랫폼' 이었다. 해당 서비스에서는 일반적으로 생각할 수 있는 '경매'도 물론 가능하고, '역경매'라는 서비스도 제공했다. '경매'는 다르게 말하면 '판매' 카테고리로 판매글을 올리고 경매시간이 되면 다른사람들이 경매에 참여할 수 있다. '역경매'는 반대로 '구매' 카테고리다. 구매하고싶은 물건을 올리면 다른사람들이 본인 물건을 어필하며 역경매가 진행된다. 이렇게 이번 서비스에서는 '판매'와 '구매'가 존재했고, 둘 모두 '거래'라는 공통점을 가지며 공통적으로 필요한 필드도 많이 존재했다. 중복이 많이 존재하면 공간의 낭비, 코드 중복, 개발자의 귀찮음 등 다양한 문제들이 생긴다. 문제를 인지를 했으니 이것을 어떻게 효율적이게 설계할지 고민해보았다. 위 사진은 프로젝트..

현재 deal은 image를 oneToMany로 가지고있음. public abstract class Deal { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private long id; @CreatedDate private LocalDateTime createTime; @LastModifiedDate private LocalDateTime updateTime; private String title; private String content; @ManyToOne(fetch = FetchType.LAZY) private Member writer; @Enumerated(EnumType.STRING) private Category category; @El..

현재 진행중인 프로젝트에서 하나의 이미지와 다른 값들을 받아서 방명록 객체를 만드는 api가 있다. 처음엔 다른 일반적인 요청을 받을때처럼 하나의 DTO를 정의해서 요청값으로 받았다. 다만 평소처럼 그냥 RequestBody를 적어주고 스웨거를 들어가면, 파일을 올릴수없고 다른 값들과 함께 Json 텍스트값을 입력받게 되어있는 것을 볼 수있다. 사진파일은 다른 값들처럼 JSON으로 보낼수 없다. 사진파일을 받기위해 MULTIPART_FORM_DATA 타입으로 요청을 받도록 했다. @Getter @Setter @NoArgsConstructor(access = AccessLevel.PROTECTED) @AllArgsConstructor public class GuestBookRequest { String n..

1. 스웨거 springfox 사용 불가 -> springdoc 사용 문법도 조금 바뀜. 2. spring security 6.2이상에서 설정 방법 변경 public final class HttpSecurity extends AbstractConfiguredSecurityBuilder implements SecurityBuilder, HttpSecurityBuilder { . . public HttpSecurity cors(Customizer corsCustomizer) throws Exception { corsCustomizer.customize(getOrApply(new CorsConfigurer())); return HttpSecurity.this; } . . } HttpSecurity를 구성할때,..

스프링 프로젝트를 만들면 application.properties 혹은 yml 파일에 각종 설정 정보를 입력하게 된다. 이 정보에는 api key, db 접속정보 등 보안정보도 포함되기 때문에 그대로 Git과 같은 온라인상에 올려버리면 낭패를 겪게된다. 이런 문제를 해결하기 위한 방법으로는 암호화 라이브러리를 사용하여 암호화하는 방법과 해당 정보를 다른 파일로 분리하고 gitignore에 추가하는 방법이 있다. 나는 정보를 다른 파일로 분리하는 방법을 사용할 것이고 git에 공개된 설정파일에서도 대략적인 코드 구성을 파악하기 쉽도록 해당 '보안데이터' 만 분리 할 것이다. 스프링 프로젝트를 할 때 항상 properties만 사용했는데 이번에는 yml파일을 사용해보고싶어서 처음으로 시도했고 yml에서는 설..

이어서 controller의 테스트 코드를 작성해 보겠다. memberAccountController @ApiOperation(value = "회원가입") @PostMapping("/join") public ResponseEntity joinPOST(@Valid @RequestBody MemberJoinDTO memberJoinDTO){ memberService.join(memberJoinDTO); //return ResponseEntity.ok(ResultResponse.of(REGISTER_SUCCESS, true)); return ResponseEntity.status(HttpStatus.CREATED).body(ResultResponse.of(REGISTER_SUCCESS, true)); } 테스..

1편에 이어서 service의 테스트 코드를 만들어 보자. memberServiceImpl @slf4j @Service @RequiredArgsConstructor public class MemberServiceImpl implements MemberService{ private final AccountUtil accountUtil; private final ModelMapper modelMapper; private final MemberRepository memberRepository; private final PostRepository postRepository; private final ScrapRepository scrapRepository; private final PasswordEncoder ..

스프링부트를 이용하여 프로젝트를 하던중 1차 개발이 끝나고 2차 개발을 시작하기 전에 컨벤션에 맞지 않는 무분별한 네이밍과 깔금하지 못한 코드들을 리팩토링하는 과정을 먼저 거쳤다. 팀원 모두 스프링에 대한 이해도가 부족한 상태에서 처음 진행하는 프로젝트다보니 테스트코드를 작성할 여유도 없었고, 어떤식으로 작성하는지도 몰랐기 때문에 테스트코드 없이 postman을 이용해 직접 테스트하며 구현했었는데, 나중에 리팩토링을 하려니 문제가 생겼다. 기존 변수명,함수명, 클래스 구조 등이 바뀌다 보니 예상치 못한 에러가 많이 발생해서 어려움을 겪었는데 테스트코드가 있었다면 이 과정이 훨씬 편해졌을 것이란걸 알고서 테스트코드의 필요성을 느꼈다. 이런 이유로 spring mvc의 테스트 코드 작성법을 공부하고 조금씩 ..

+ 내용 추가 프론트에서 카카오 로그인 - 인가코드를 받는 부분까지 처리하고 인가코드를 백엔드에게 넘겨준 후에 나머지 처리하는 로직이 일반적으로 프론트와 백엔드가 분리되어있을 때 사용하는 방식은 맞지만 몇가지 문제가 더있었다. 프론트에서 웹뷰를 사용한다면 이런 로직으로 구현하는데 전혀 문제가 없고 주로 사용하는 방법이다. 그런데 우리 프론트는 flutter를 사용하고 있었고, flutter에서 카카오가 제공해주는 로그인 api를 사용하기 위한 방법은 두가지가 있다. 웹뷰에서 사용할 수 있는 redirect방식 네이티브에서 사용할 수 있도록 기능을 제공하는 sdk 아래에 구현한 내용은 일반적으로 1번 방식에서 가능한 방식이다. 네이티브에서 사용하는 sdk는 인가코드만 달랑 받아와서 따로 서버에 전달할 수 ..