Hello backEnd

https://hello-backend.tistory.com/335 IntelliJ plugin을 만들고 배포해 보자 - method tester (3)IntelliJ plugin을 만들고 배포해 보자 - method tester (3)(이 내용은 플러그인의 테스트와 배포에 관한 내용이다. 구현 부분은 이전 글을 참고하면 좋다.)만들었으니 이거를 테스트하고 배포해 보면 된hello-backend.tistory.com지금까지 IntelliJ 에서 Plugin을 만들고 이를 배포해 보았다.그런데 이게 변경이 필요할 때가 있다. 이 때에 플러그인에 어떻게 반영하는지 빠르게 알아보자. - build.gradle.kts파일을 보면 version =  어쩌고 이런게 있다.거기서 버전을 하나 올려준다.version ..

IntelliJ plugin을 만들고 배포해 보자 - method tester (3)(이 내용은 플러그인의 테스트와 배포에 관한 내용이다. 구현 부분은 이전 글을 참고하면 좋다.)만들었으니 이거를 테스트하고 배포해 보면 된다.(사실 근데 테스트는 이미 많이 해야한다 나는 처음부터 된 것처럼 썼지만 엄청 테스트 많이함)Test 방법인텔리제이 오른쪽에 build.gradle을 보면요렇게 선택된 두개가 있다.먼저 runIde에 대해 설명하면저거 한번 수행해보면 intelliJ community 였나? 아무튼 인텔리제이 프로젝트 하나가 나오게 될 것이다.이게 테스트 환경이라고 생각하면 된다.저기서 원하는 프로젝트를 만들거나 열고, 이후에 테스트를 진행해 본다.좋은 점은 문제가 있거나 확인할 부분들이 플러그인 콘..

IntelliJ plugin을 만들고 배포해 보자 - method tester (2)(이 내용은 플러그인의 구성 요소와 내용에 관한 글이다. 어떤 로직을 어떻게 구현했는지와 대략적인 플러그인 플로우에 관한 것.)이전 글에서 어떤 것을 만들지에 대한 내용을 찾았다.그러면 이를 실제로 한번 만들어 볼 것이다.https://github.com/JetBrains/intellij-platform-plugin-template젯브레인에서는 플러그인을 만들기 위한 템플렛을 지원한다.플러그인을 만들기 위해서 여기서 fork해서 템플렛을 복제한다.그리고 하나씩 원하는 기능을 만들어 보면 된다.plugin.xml플러그인의 정보와 이후 기능을 부여할 action 동작에 관한 기본적인 정의를 하는 부분이라고 생각하면 된다. ..

IntelliJ plugin을 만들고 배포해 보자 - method tester (1)(이 내용은 어떤 플러그인을 만들까에 대한 내용이다. 만드는 방식은 이후에 적을 예정이다.)개발을 하면서 프로젝트의 크기가 커지고 기능을 잘 나누어 둔다면 하나의 메서드를 여기저기서 재활용하는 경우가 참 많아지게 된다.그리고 이를 처음에 만들 때에는 잘 만들어 두었고 더이상 변경의 여지가 없을 거라고 생각했는데, 어떠한 이유로 리팩터링을 진행할 수 있다.근데 그렇게 되면 이게 잘 고쳐졌는지, 다른 로직에 이상이 없는지를 바로 테스트하기가 참 애매하다.예를 들어, 다음과 같은 클래스가 있다고 가정해 보자.import org.springframework.stereotype.Component;@Componentpublic cl..

spring boot의 self invocation, 이유와 해결법 회사에서 개발하는데 캐싱과 관련하여 self invocation 관련해서 이슈를 들었다. 그래서 한번 찾아보게 되었다. invocation 이거는 메서드 호출이라고 생각하면 된다. self-Injection?? 일단 문제상황에 대해 알아본다 다음과 같은 코드를 작성한다. (그리고 캐시 설정은 되어있다고 가정한다.) Ryoochan.java import jakarta.persistence.Entity; import jakarta.persistence.GeneratedValue; import jakarta.persistence.GenerationType; import jakarta.persistence.Id; @Entity public cl..

querydsl에서 다대다 구현하기. 일대다-다대일(feat. Result Aggregation) 보통 다대다 매핑을 할 때에는 일대다 - 다대일로 매핑하도록 시킨다. 이 이유는 어차피 JPA에서 만든 후에 이를 처리해주기 위한 중간 테이블을 생성하게 된다. 근데 이 테이블을 사용하는 동안 정체모를 쿼리가 발생할 가능성이 있다. 중간 테이블에도 메타 데이터 등의 추가 쿼리가 필요할 수 있는데, 이를 다대다에서는 개발자가 넣어줄 수 없다. 암튼 그래서... 일대다 다대일로 하는데, 여기서 하나의 파트에서 반대 파트의 데이터를 가져오는 방법을 살펴보도록 한다. 상황 먼저 프로젝트 밈위키 에서는 대충 뭐 이런 느낌으로 "밈 - 태그" 를 갖고 있다. 이는 생각해보면 이렇게 밈과 태그가 다대다로 묶여 있어서 밈..

save랑 saveAll(feat. Transactional) Spring Data JPA를 통해 다양한 쿼링을 쉽게 해줄 수 있다. 근데 만약에 여러 insert를 해줘야 하는 경우가 있다면 어쩔까?? 상황 일단 Spring Data JPA에 대해 안다고 가정한다. 여러 값을 저장할 때에 save방식 넣을값들.forEach( index -> 저장레포지터리.save(index) )이거랑 saveAll방식 저장레포지터리.saveAll(넣을값들);의 차이가 뭘까?? save 일단 save를 한번 본다. saveAll 이제 saveAll을 본다 뭐가 다른겨? 사실 saveAll을 보면 최초에 Transactional 어노테이션 실행 해당 함수 내에서 save함수 실행 저 save는 save함수임 이렇게 간다...

서비스를 실제로 운영할 때에 공격이 들어올 수 있고, 이를 막기 위해 노력해야 한다. 디프만에서 우리는 모든 DB통신을 JPA와 querydsl을 통해 진행했기 때문에 SQL injection은 막을 수 있었다. 그러나 XSS의 경우는 추가적인 방어가 필요했다. 이를 위해 lucy filter를 도입하였고, 우리 프로젝트에 맞춰 추가적인 기능을 부여하며 여러 테스트를 해 보았다. lucy필터의 장점 https://github.com/naver/lucy-xss-filter 네이버에서 만든 XSS 방어용 필터이다. 이를 사용하면 XML설정만으로 XSS방어가 가능해진다. 비지니스 레이어의 코드 수정이 필요하지 않다. 직접 설정할 필요가 없으므로 코드를 잘못 입력하거나, 놓치고 적용하지 않는 경우가 없다. lu..

Spring boot로 간단한 rest api를 구현하여 보자!! Spring boot를 통한 REST API의 구현 - 실습(3)에 관한 이론과 내용들에 관한 글이다. 관련 내용 1. Lombok 개념 Lombok이란, 반복해서 사용되는 Annotation을 하나로 묶어서 자동으로 작성해주는 라이브러리이다. 자주 쓰이는 내용들을 한꺼번에 적용할 수 있고 긴 코드를 줄여주기 때문에 생산성에 큰 도움이 되지만, 생각보다 큰 단점이 존재한다. 이 단점에 관해서는 이후에 단점이 발생하게 되는 타이밍에 다시 적겠다. 이게 꼭 그 상황이 터져야 비로소 이해하게 되는 것 같다. 사용 @Data @Getter / @Setter / @ToString / @EqualsAndHashCode / @RequiredArgsCo..

Spring boot로 간단한 rest api를 구현하여 보자!! DTO를 사용한 값 전달, default설정 등 DTO를 사용한 값 세팅 및 전달하기 default값 설정과 required 설정하기 DTO생성 해당 위치에 UserInfoDTO라는 java class를 하나 생성해 준다. import lombok.Data; import lombok.NoArgsConstructor; @Data @NoArgsConstructor public class UserInfoDTO { private String name; private String email; } 해당 클래스의 코드는 다음과 같다. 참고로 여기서 @Data, @NoArgsConstructor을 사용하려면 lombok을 import해줘야 할 것이다. ..