일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- Spring Boot
- Word Cloud
- 파이썬
- 브랜디
- terraform
- Python
- FastAPI
- 프로그래머스 코딩테스트 연습
- 프로그래머스 코딩 테스트 연습
- 스프링 부트와 AWS로 혼자 구현하는 웹 서비스
- 프로그래머스 월간 코드 챌린지 시즌1
- c#
- github actions
- selenium
- 애드센스
- Firefox
- PostgreSQL
- 디자인 패턴
- github
- 클린 코드
- PostgreSQL 설치 시 에러
- 스코페2021
- 프로그래머스 코딩테스트 연습문제
- git
- heroku
- Codeforces
- pycharm
- WPF
- 바이오데이터 엔지니어
- 프로그래머스 월간 코드 챌린지
- Today
- Total
목록Spring Boot (11)
프로그래밍 연습하기
기존 프로젝트에서 누구나 글을 삭제할 수 있었습니다. 그래서 PostService와 PostApiController를 수정하여 현재 로그인 유저 이름을 가져오고, 해당 글을 쓴 사람과 같을 때만 삭제하도록 했습니다. 추가하면서 생각해본 점은 만약 아이디를 바꿀 수 있다면 내가 이전에 쓴 글은 어떻게 지워야 하나? 라는 생각이 문득 들었습니다. 아이디는 그대로 두고 닉네임 같은 것을 추가하여서 자유롭게 바꿀 수 있도록 하고 바뀌지 않는 값 끼리 비교를 해야하나? 아니면 유저에 작성한 글과 댓글을 추가하면서 유저가 작성한 글과 댓글만 삭제할 수 있게 한다던가? 실제 서비스 중인 어느 게시판은 상황에 따른 response를 해주고 프론트에서 그 값을 이용하여 처리하는 것으로 보입니다. 좀 더 고민해 봐야 할 ..
저번에 댓글 추가까지만 구현하고 삭제는 이번에 구현하였다. 생성되는 댓글에 삭제하는 버튼도 같이 생성되게 하고, 댓글 테이블 마다 댓글 id 속성값을 넣었다. 그리고 제이쿼리를 사용하여 모든 댓글삭제 버튼에 id속성값을 이용해 댓글 삭제api를 호출하였다. 처음에는 댓글이 안지워져서 헤맸는데, 원인은 내가 댓글 Dto를 생성할때 id를 안넣었었고, 그래서 머스테치에서도 id를 읽어올 수 없었다. 대신에 이름이 같은 글번호를 읽어오고 있었다. 기본적으로 model에 들어가는 값에 대해 생각해봤어야 하는데 중복되는 이름이라 혹시 오류가 생긴건가 해서 애꿎은 머스테치의 오류를 찾느라 좀 헤멨다. 또다른 문제는 제일 처음 댓글 삭제 버튼만 작동하는 것이었다. 그 문제는 내가 제이쿼리를 작성할때 태그 id를 이용..
기존에 완성했던 프로젝트에 댓글 기능을 추가해보고 있다. 기능을 추가하면서 아직 프로젝트를 완벽하게 이해하지 못했다는 느낌이 들었다. 기존의 글과 비슷한 기능이지만 책을 보고 프로젝트를 완성한 것과 직접 작성해보는 느낌은 달랐다. 댓글을 새롭게 DB에 추가하고, domain, repository, service를 만들고 댓글 api controller, dto까지 작성을 해봤는데 예상보다 오랜 시간이 걸렸다. 댓글 JPA Repository를 만들면서 예상치 못한 에러가 나오기도 하였다. 메소드 이름을 잘못 작성한것 같아 일단 쿼리로 바꾸어서 적용을 하였다. 또한 화면을 구성하는 것도 마음대로 나오지 않아 고생했다. 그리고 @LoginUser를 이용해서 글/댓글 작성자의 아이디를 따로 입력받지 않고 로그..
어느새 책의 마지막 장인 무중단 배포까지 왔다. 이번 장에서도 역시 많은 오타로 수정을 거듭한 결과 두 개의 애플리케이션을 이용하여 중단 없이 배포를 성공하였다. profile을 확인하여 실행중인 애플리케이션이 달라지는 것도 확인할 수 있었다. 간단하게 과정을 설명하자면 애플리케이션 2개 중 Nginx와 연결되지 않은 곳에 배포를 하고 배포가 되어 제대로 작동되면 Nginx가 그 애플리케이션과 연결되어서 중단 없는 배포가 이루어진다. 마지막 11장은 프로젝트에 관한 내용은 아니고 저자가 1인 개발을 할 때의 방향성을 잡아주고 몇 가지 서비스를 추천해준다. 따라서 10장까지가 프로젝트의 내용을 담고 있다. 이 책을 읽고 프로젝트를 해보면서 많은 것을 새롭게 해볼 수 있어서 도움이 되었다. 자바와 스프링 부..
8장, 9장에서는 배포를 하고 배포를 자동화하였다. 이전까지의 과정은 디테일에서는 좀 차이가 있지만 내가 개인 프로젝트를 하면서 어느정도 경험해본 부분이었다. 여기서부터는 처음 경험해보는 것이라 신기하고 낯선 부분이 많았다. CI (Continuous Integration) / CD (Continuous Deployment) 라고 하는 개념을 직접 실습해보면서 어느정도 감을 잡을 수 있게 되었다. 이렇게 내가 겪어보지 않은 과정이 있다는 것이 책을 구매한 이유 중 하나이기도 했다. 이 단계에서는 리눅스 환경과 쉘 스크립트도 사용을 했는데 전공 수업때 어느정도 해본 경험이 있었다. 그렇게 낯설지는 않아서 크게 어렵지 않게 진행할 수 있었다. Github에 푸쉬를 하면 Travis CI가 AWS S3에 ja..
6장, 7장이 내용이 많지 않고 설정 위주라서 한번에 작성하였다. 6장은 AWS에 가입하고 EC2 서버를 설정하는 하는 내용이었다. 내용이 많지 않고 단순히 따라가며 설정하는 내용이 주를 이뤘다. 마지막에 ssh 접속을 하기 위한 프로그램으로 책에서는 putty를 사용했는데, 내가 전공 수업을 들을때나 개인적인 프로젝트 목적으로 네이버 클라우드 서비스를 이용했을 때 사용했던 xshell 이라는 프로그램이 조금 더 사용하기 좋은 것 같아서 나는 xshell로 진행 해보려고 한다. 네이버 클라우드 서비스를 이용했을 때 xshell에선 pem키를 따로 변환하지 않고도 그대로 사용했던 기억이 있었기 때문이다. 7장은 AWS RDS 설정을 하였다. 데이터베이스로는 MySQL 에 비해 장점이 몇개 더 있는 Mari..
이번 장에서는 스프링 시큐리티와 OAuth2.0을 구현한 구글 로그인, 네이버 로그인과 같은 소셜 로그인 기능을 만들었다. OAuth2.0을 간단히 정의하면 서로 다른 서비스에서 요청자의 정보를 안전하게 공유할 수 있게 해주는 프로토콜이다. 구글 로그인이나 네이버 로그인과 같은 것들을 사용하면 어디에서 사용자의 정보를 공유한다는 확인 메세지를 볼 수 있다. 이런 서비스가 OAuth2.0을 이용한 서비스이다. 예전에 블로그를 자동으로 작성하는 봇을 만들어 보려고 구글 API를 좀 만져 봤었고, 네이버에서도 단축 URL이라던지 하는 오픈 API를 활용해 보기 위해 계정을 만들고 뭔가 해봤던 때의 생각이 났다. 이번에는 개인 API 키와 같은 개인 정보를 다루기 때문에 설정 파일을 gitignore를 이용해서..
4장에서는 머스테치(Mustache)를 이용하여 화면을 만들어 보았다. 많은 템플릿 엔진 중에서 머스테치를 사용한 이유는, 문법이 간단하고 로직 코드를 사용할수 없어 View와 서버의 역할이 분리되기 때문이다. 메인화면과 게시글 등록, 수정 화면 등 필요한 기능의 화면과 API를 작성하였다. 실습 도중 확인을 해보는데 수정을 하면 글 제목이 사라지는 에러가 있었다. h2 console을 확인해보고 DB에 제목이 없는 것을 확인했다. 제목 입력과 관련된 부분을 살펴보니 글 수정 페이지와 자바스크립트에 오타가 있었다. 화면 구성을 책에서는 코드가 양이 많아 복붙하는 것을 권했었는데 나는 직접 쳐봤었다. 그래서 그런지 오타때문에 에러가 발생했었는데, 그래도 에러를 나는 이유를 찾아본 것이 코드를 더 이해하는데..
3장에서는 JPA로 데이터베이스를 다루게 된다. JPA에 대해 설명해주고 데이터베이스를 다루는 코드들과 테스트를 작성해보게 된다. SQL을 사용하는 것은 많은 단순 반복작업, 객체지향 프로그래밍과 패러다임이 맞지 않는 등의 문제가 있다. JPA는 객체지향적 프로그래밍을 관계형 데이터베이스에 맞게 SQL을 대신 생성하여 실행해준다. JPA는 인터페이스이고 사용하기 위해 구현체가 필요한데, 이 프로젝트에서는 Hibernate를 사용한다. 그 구현체를 좀 더 쉽게 추상화시켜 Spring Data JPA라는 모듈을 이용한다. JPA
2장에서는 테스트 작성에 관한 부분을 다루고 있다. 테스트의 중요성에 대해서 먼저 설명해주고, 테스트를 만들어 보면서 스프링 부트의 WAS에도 설명을 해준다. 스프링 부트는 내장 WAS를 사용하여 톰캣을 따로 설치하지 않는다. 이는 WAS의 관리에 있어서 장점을 갖게 된다. 따로 설치하면 여러 대의 서버를 관리하는 경우 관리가 힘들어지기 때문이다. 따라서 내장 WAS를 사용하는 것이 권장되는 추세이고, 성능 상의 이슈 또한 별 문제가 되지 않는 수준이라고 한다. 테스트 코드를 작성하면서 @Autowired라는 어노테이션을 볼 수 있었다. 이 어노테이션은 그 동안 스프링을 공부하면서 많이 봤었는데, 역할을 정확히 알지 못했다. @Autowired를 통해서 XML이나 class로 bean 설정을 하지 않고도..