seungjjun의 등록된 링크

키자드에 등록된 총 224개의 포스트를 확인하실 수 있습니다.

Tistory

프로세스란? (PCB, Context Switching)

프로세스(Process) 프로세스를 간단히 표현하면 실행중인 프로그램이라고 표현할 수 있다. 구체적으로 메모리 상에서 실행 중인 프로그램으로 운영체제로부터 자원(주소 공간, 파일, 메모리)을 할당 받을 수 있는 것을 말한다. 모든 프로세스는 실행을 위해서 CPU를 필요로 하는데, CPU의 자원은 한정되어 있기 때문에 프로세스가 CPU를 동시에 사용할 수 없다. 즉, 프로세스들은 실행을 위해 각자 자신의 차례를 기다리며 할당받은 시간만큼만 CPU를 이용한다. OS는 이렇게 프로세스의 실행을 관리하기 위해 프로세스 제어 블록(PCB)이란것을 이용한다. 프로세스 제어 블록(Process Control Block, PCB) 프로세스 제어 블록(PCB)이란 프로세스에 대한 중요한 정보들을 저장하고 있는 자료구조이..

원문보기 내부링크
Tistory

HTTPS란 무엇인가?

HTTPS에 대해 간단히 알아보자. 우선 HTTPS를 알기 위해선 HTTP에 대한 기본적인 지식이 필요하다. 얼마 전에 HTTP에 대해 간단히 설명한 글이다. https://seungjjun.tistory.com/223 HTTP란? 웹을 배우지 않아도 인터넷을 한번이라도 사용했다면 주소창에서 볼 수 있는 HTTP에 대해서 간단히 정리해보려고 한다. HTTP란??? 우선 HTTP의 정의부터 알아보자. HTTP는 Hyper Text Trasnsfer Protocol의 약 seungjjun.tistory.com HTTPS란? HTTPS(Hypertext Transfer Protocol Secure)를 간단하게 정의하면 HTTP 프로토콜의 보안이 강화된 버전이라고 할 수 있다. HTTPS는 소켓 통신에서 일반 ..

원문보기 내부링크
Tistory

TCP와 UDP의 특징 (3-way-handshaking, 4-way-handshaking)

TCP와 UDP는 OSI 7계층의 전송계층에서 사용되는 프로토콜이다. 전송계층을 간단히 설명하면 송신자와 수신자를 연결해 데이터의 전달을 담당하는 계층이라고 생각하면 된다. 먼저 TCP부터 알아보자. TCP(Trasmission Control Protocol) TCP는 연결 지향적 프로토콜이며, 손실되면 안되는 중요한 데이터(웹, 이메일, 파일 등등)를 주고받을 때 통신의 신뢰성을 높이기 위해 사용한다. 연결 지향 프로토콜이란 클라이언트와 서버가 연결된 상태에서 데이터를 주고받는 프로토콜을 의미한다. 데이터를 전송하기 위해서는 클라이언트와 서버가 연결이 되어야 하는데 클라이언트와 서버 간에 연결을 하기 위해서 3-way-handshaking 과정을 통해 연결이 되고, 데이터 전송이 끝나면 4-way-ha..

원문보기 내부링크
Tistory

2022년을 보내며

2022년 나의 발자취를 되돌아보았다. 1. 시작 2022년은 치열했고 지금까지 가장 의미 있게 보냈다고 자부할 수 있는 한 해였다. 어렸을 때부터 조립하면서 뭔가를 만들어 동작시키는 것을 좋아해 로봇공학자가 꿈이었었는데 대학 입시에 실패하면서 자연스럽게 꿈을 접었었다. 그러다 군대에서 우연히 누군가 코딩하는 것을 보게 되었고 단순히 그 모습이 멋있어 보였던 나는 코딩에 대해 알아보기 시작했고 전역 이후에 유튜브에 있는 여러 코딩 강의를 따라 해 봤는데, 재미있었다. 본격적으로 배우고 싶다는 생각이 들었고 마침 학교에서 비전공자를 대상으로 프로그래밍을 교육해주는 동아리가 있다는 것을 알게 되었고, 나의 2022년 첫 목표가 정해졌다. '멋쟁이 사자처럼' 동아리에 들어가는 것이었다. 코딩이 한창 열풍이다 ..

원문보기 내부링크
Tistory

HTTP란?

웹을 배우지 않아도 인터넷을 한번이라도 사용했다면 주소창에서 볼 수 있는 HTTP에 대해서 간단히 정리해보려고 한다. HTTP란??? 우선 HTTP의 정의부터 알아보자. HTTP는 Hyper Text Trasnsfer Protocol의 약자로 웹에서 리소스(데이터)를 주고 받을 수 있는 프로토콜이다. 프로토콜은 "약속"을 의미한다. 조금 더 와닿게 설명하면 HTTP는 웹에서 서버와 클라이언트간에 리소스를 주고 받기 위한 약속을 말한다. 그러면 웹에서 리소스를 주고 받기 위해 약속을 정한 이유는 무엇일까? 약속을 정하지 않고 서로 다른 하드웨어와 운영체제, 무엇 하나 같은게 없는 컴퓨터끼리 웹에서 통신을 한다고 한번 상상해보자. 그러면 서로 통신을 하기 위해 자신만의 방법으로 데이터를 요청하고 보내려고 할..

원문보기 내부링크
Tistory

JVM(Java Virtual Machine)이란?

JVM이란? JVM(Java Virtual Machine)은 자바를 실행하기 위한 가상 기계로 Java의 특징 중 하나인 OS에 종속받지 않고 사용할 수 있는 특징을 가능하게 해주는 도구이다. JVM이 Java와 OS사이에서 중개자 역할을 수행하기 때문에 Java가 OS에 종속받지 않고 사용을 가능하게 해준다. 그리고 메모리 관리(Garbage Collection)도 수행한다. JVM 구성 요소 Class Loader Class Loader는 클래스 파일(.class file)을 JVM이 OS로 부터 할당받은 메모리 영역(Runtime Data Area)으로 로딩하는 역할을 한다. Execution Engine 클래스 로더가 메모리(Runtime Data Area)에 클래스 파일들을 적재시켰다면 실행 엔..

원문보기 내부링크
Tistory

가비지 컬렉션(Garbage Collection)이란?

가비지 컬렉션(Garbage Collection, GC) C/C++과 달리 자바는 개발자가 명시적으로 객체를 해체할 필요가 없다. 이는 자바의 장점 중 하나이다. 사용하지 않는 객체를 메모리에서 삭제하는 작업을 GC라고 부른다. 가비지 컬렉션은 동적으로 할당된 메모리 영역 중 사용하지 않는 영역(쓰레기)를 찾아 지우는 역할을 한다. GC에 대해 자세히 알기 전에 'stop-the-world'를 먼저 살펴보자. stop-the-world? GC를 실행하기 위해 JVM은 애플리케이션 실행을 멈추게 하는데 이를 'stop-the-world(STW)'라고 한다. 모든 GC는 STW를 발생시키는데 STW가 발생하면 GC를 실행하는 Thread를 제외하고 모든 Thread는 작업을 멈춘다. GC 작업이 완료되어야 ..

원문보기 내부링크
Tistory

221222 TIL Bucket4J를 이용해 외부 api 관리

KiCK OFF 프로젝트에서 축구 경기 일정을 조회하기 위해 무료(인줄 알았던..) api인 rapid api를 사용하고 있었다. 그런데 11월 말 코딩을 하던 중 핸드포네서 "띠링" 소리가 울렸다. 확인해보니 카드 결제소리 였다.. 자동이체 해놓은게 없는데 돈이 빠져나가 확인해보니 RAPIDAPI 에서 자동으로 6,770원을 뺏어(?)갔다.. 부리나케 rapid api 사이트에 가서 pricing 부분을 다시 확인해보니 하루에 100번 요청까지만 무료고 다음 요청부터는 0.005달러씩 추가 요금이 발생한다고 적혀있었다. 뭐 아무튼 6,770원만 빠져나간걸 감사하게 생각하고 급한대로 경기 요청 api는 우선 사용하지 못하도록 막아놨었다. 해당 api를 사용하는 부분은 모두 구현을 했기 때문에 배포 전까지..

원문보기 내부링크
Tistory

KiCK OFF 프로젝트 회고

1. KiCK OFF 배포 링크 : http://kick-off.tech 시연 영상 편집이 허접하지만 이런 기능들이 있다 이정도로만 봐주세요. 어드민 시연 영상 1-1) 프로젝트 소개 및 선정이유 "KiCK OFF"라는 프로젝트는 축구를 즐겨보는 사람들이 서로 축구 관련 정보를 공유하고 해외 축구 경기 일정이나 경기 정보들을 얻을 수 있으며 실시간으로 사용자끼리 응원할 수 있는 서비스를 제공하는 커뮤니티 프로젝트이다. 이 프로젝트를 선정하게 된 이유는 매우 심플하다. 프로젝트 아이디어 선정 당시 어떤 도메인으로 프로젝트를 진행할지 생각하는 시간이 있었는데 나는 한 치의 고민도 없이 "축구"를 선택하였다. 내가 제일 잘 알고 가장 좋아하는 영역이었기 때문이다. 그런데 도메인을 빠르게 정한 것 치고는 축구라..

원문보기 내부링크
Tistory

221207 TIL 어떤 게시판에 게시글이 가장 많을까?

오늘은 최상위 게시판(EPL, LaLiga, SerieA, Bundesliga) 4개 중 어떤 게시판의 비중이 가장 큰지 알기 위해 4대 리그 게시판별 게시글을 종합하는 작업을 했다. 예를 들어 EPL 게시판을 부모로 갖고 있는 하위 게시판에 있는 게시글을 모두 종합하는 작업이다. 그런데 리그 게시판이 하위 게시판들의의 게시글을 갖고 있지 않아 findAll 같이 간단하게 구할 수 있는 문제가 아니였기 때문에 어떻게 모든 게시판의 게시글을 찾을지 고민을 했다. 우선 게시판의 구조가 총 3 depth(리그 게시판 -> 팀 게시판 -> 선수 게시판)로 구성된 게시판이기 때문에 리그 게시판을 부모로 갖고 있는 모든 팀 게시판을 리스트로 담아 팀 게시판 하나하나당 게시글의 개수를 더한 다음 또 팀 게시판 하나하..

원문보기 내부링크
Tistory

221208 TIL useLocalStorage

오늘은 오전, 오후에는 css작업을 어느 정도 하고 저녁에는 어드민 로그인을 구현했다. 어드민에는 회원가입도 필요 없고 로그인도 기존에 사용자단에서 로그인 시 필요한 인터셉터와 jwt가 이미 만들어져 있었기 때문에 금방 만들 수 있을 거라고 생각했다. 일단 어드민 계정 생성을 위해 엔티티를 만들어 주고 어드민 계정은 db에 직접 하나 넣어줬다. 이후 로그인 시 프론트에서 입력받은 계정이 어드민 계정인지 아닌지 검증하기 위한 로직을 작성해주고 로그인이 성공하면 입력받은 아이디를 jwt를 이용해 토큰으로 만들어서 해당 토큰을 프론트로 전달했다. db에 넣어준 어드민 계정으로 로그인 성공 시 토큰이 잘 전달되는지 로그인을 해봤는데 정상적으로 accessToken을 받은 것까지 확인할 수 있었다. 이제 어드민 ..

원문보기 내부링크
Tistory

221209 TIL 채팅 입력시 자동으로 scroll 맨 밑으로 이동하게 하기

오늘은 채팅창 css를 적용하다 수정해야 할 부분이 생겨서 다시 채팅창을 리팩터링 하는 작업을 했다. 문제 상황은 채팅 메시지가 채팅창의 세로 사이즈가 넘어갈 시 overflow-y: auto를 줘서 자동으로 세로 스크롤이 생기게 했다. 그런데 채팅을 새로 입력했을때 세로 스크롤만 생기지 스크롤이 자동으로 맨 밑으로 내려가는 게 아니라 사용자가 직접 스크롤을 내려서 최신 메시지를 확인해야 하는 문제가 발생했다. 그래서 채팅을 입력했을때 자동으로 스크롤이 맨 밑으로 내려가게 하는 방법을 찾아 해결했다. useRef useRef를 사용했는데 useRef를 간단히 말하면 React에서 특정 DOM요소에 접근할 때 사용하는 hook이다. 자바스크립트를 사용할 경우에는 getElementById나 querySel..

원문보기 내부링크
Tistory

221210 TIL 클릭 효과 유지 하기

오늘은 어드민 페이지 css 작업을 끝냈다. 그중 게시판을 관리하는 페이지의 css를 적용할 때 시간이 꽤나 걸렸었는데 그 이유가 메뉴를 클릭했을 때 클릭한 메뉴의 글씨 색이 변한 상태로 유지되도록 css를 적용하고 싶었기 때문이다. 메뉴를 클릭했을 때 글씨 색을 변하게 하는 속성 중 active 속성이 있었는데 active속성을 적용하면 메뉴를 클릭했을 때 그 순간에만 메뉴 색이 변경이 되어서 내가 구현하고 싶은 기능과는 달랐다. 위 css를 적용하기 위해 처음에 이용했던 방법은 useState를 이용해 isSelected를 만들어서 초기값은 false로 주고 메뉴를 클릭하면 onClick함수에 setIsSelected를 true로 바꿔 isSelected가 true이면 해당 태그의 색을 변경하는 식으..

원문보기 내부링크
Tistory

221205 TIL 내 채팅과 다른 사용자의 채팅 구분하기

오늘은 기존에 구현했던 채팅 기능을 더 보완하는 작업을 했다. 작업 목표는 카카오톡처럼 자신이 쓴 채팅과 상대방이 쓴 채팅의 말풍선 색이 다르게 보이도록 하고, 상대방의 채팅 말풍선에 상대방의 닉네임을 노출시키도록 하는 것이었다. 기존에는 누가 채팅을 치든 구분이 안되어서 익명 채팅방 같은 느낌이었는데 말풍선과 닉네임을 노출시켜 구분이 가도록 하는 것이었다. 우선 위와 같은 기능을 구현하기 위해 고민했던 건 자신이 쓴 채팅과 다른 사용자가 쓴 채팅을 어떻게 구별할지였다. 우선 두 가지 방법을 떠올렸는데 아래와 같다. 1. 채팅을 보낼 때 아래와 같이 자신의 닉네임(writer)을 같이 보내게 했기 때문에 메시지를 받는 사용자도 writer가 누구인지 알 수 있어 메시지를 받을 때 writer와 현재 로그..

원문보기 내부링크
Tistory

메가테라 23주차 주간회고 (프로젝트 7주차 회고)

23주 차 회고 (프로젝트 7주 차 회고) 메가 테라 23주 차를 진행하면서 있었던 일을 종합해서 회고하였습니다. 7주 차 작업 목표 7주 차의 가장 큰 목표는 어드민 기능을 핵심적인 것부터 최대한 많이 구현하는 것이었다. 그래서 기존에 계획했던 게시판의 어드민 기능 중 가장 핵심적이고, 없으면 안 되는 기능 3가지를 뽑아 무조건 구현하도록 최우선 순위로 선정했다. 핵심적인 3가지 기능은 아래와 같다. 1. 전체 멤버 관리 전체 멤버 수를 확인할 수 있다. 멤버의 등급을 변경할 수 있다. 멤버를 강제 탈퇴시킬 수 있다. 회원 정보(아이디, 닉네임, 등급, 게시글 작성 수, 댓글 작성 수)를 확인할 수 있다. 2. 게시판 관리 하위 게시판 생성 (3 depth) 게시판 삭제 3. 등업 신청 관리 등업 신청..

원문보기 내부링크
Tistory

221206 TIL 조회수 순으로 게시글 가져오기

오늘은 어드민 기능 중 인기 게시글을 파악하기 위한 통계 관련 기능을 구현하는 것을 목표로 했다. 조회수가 가장 높은 게시글 순위, 댓글이 가장 많이 달린 게시글 순위, 좋아요를 가장 많이 받은 게시글 순위 이렇게 세 가지 순위를 통계자료로 보여주기로 기획했었다. 조회수가 가장 높은순으로 게시글 3개를 어떻게 가져올까 생각하다 이전에 동료 한분이 평점순으로 장소를 가져오려고 했던 게 생각이 났다. 조회수 순으로 가져오는거랑 평점순으로 가져오라 방법은 똑같을 거라고 생각을 해 아샬 님이 평점순으로 장소를 가져오는 방법에 대해 답변을 주신 메가 오버플로우를 찾아봤는데 findTop3 OrderBy~~ 이런 형태로 가져올 수 있다는것을 알게 되었다. 바로 아래와 같이 코드를 작성했다. Hit(조회수)를 기준으..

원문보기 내부링크
Tistory

221201 TIL 관리자 페이지에서 회원 정보 불러오기

오늘의 작업 목표는 관리자 페이지에서 모든 회원 정보(아이디, 닉네임, 프로필 사진, 작성한 게시글 수, 작성한 댓글 + 대댓글 수)를 확인하고 선택한 사용자의 등급을 변경하거나 강제 탈퇴시키는 기능 그리고 사용자의 아이디를 입력하면 해당 사용자를 찾아오는 기능을 구현하는 것이었다. 우선 작업 결과에 대해 먼저 말하면 계획한 기능을 모두 구현하지 못했다. 계획을 세우면서도 약간 무리하는 것 같은 느낌도 있었지만 이 정도는 해야 일정 안에 최소한의 관리자 기능은 만들 수 있을 것 같아 진행했었는데... 그래도 회원 정보를 불러오는 것과 선택한 유저의 등급을 변경하는 기능은 구현했다. 체크박스로 선택한 사용자의 등급을 변경하는건 이전에 마이페이지에서 선택 한 게시글이나 댓글을 지우는 갓을 구현한 적이 있었기..

원문보기 내부링크
Tistory

221202 TIL 사용자 강제 탈퇴시키기

어제 구현하지 못해 오늘로 미뤄진 작업인 관리자 페이지에서 사용자를 강제 탈퇴하는 기능을 구현해봤다. 사용자를 DB에서 지우기 위해서는 해당 사용자의 아이디를 칼럼으로 갖고 있는 Entity도 같이 제거해줘야 했다. 사용자가 작성한 게시글, 댓글, 대댓글이 있는데 여기서도 게시글과 댓글, 대댓글 사이에 연관관계가 맺어져 있어 지우는 순서도 중요했다. 대댓글이 댓글의 아이디를 갖고 있고 댓글이 게시글의 아이디를 갖고 있기 때문에 지우는 순서를 대댓글 -> 댓글 -> 게시글 순으로 지운 다음 사용자를 제거해야 했다. 그런데 위와 같은 과정을 거치지 않고 Entity를 지울때 연관관계에 있는 모든 것들을 한 번에 같이 지우는 방법이 JPA에 존재하지 않을까 생각해서 검색을 해봤다. 역시 특정 entity를 지..

원문보기 내부링크
Tistory

221203 TIL 하위 게시판 생성하기

오늘의 작업 목표는 게시판을 생성하는 기능인데 게시판을 그냥 생성하는 게 아니라 게시판 하나를 선택하면 선택한 게시판의 하위 게시판이 생기는 기능이었다. 예를 들어 EPL 게시판이 존재하면 하위 게시판으로 토트넘, 아스날 등등 팀 게시판을 생성할 수 있고 또 토트넘 팀 게시판에 손흥민, 헤리케인 같은 선수 게시판을 생성하는 것이었다. 기존에 게시판 Entity를 만들 때 위와 같은 기능을 구현하기 위해 게시판 Entity를 설계할 때 게시판 필드에 상위 게시판 아이디 값을 참조하기 위한 parentId 값을 생성했었다. 그래서 관리자 페이지에서 게시판을 생성할 때 작업 설계를 아래와 같이 했다. 1. 관리자 페이지에 현재 게시판을 리스트 시킨다. 2. 현재 존재하는 게시판 중 하위 게시판을 생성할 게시판..

원문보기 내부링크
Tistory

221204 TIL 등업 신청 현황 확인하기

오늘은 등업 신청 관련해서 마음에 들지 않는 부분이 있어 기능을 좀 더 보완해봤다. 이전에 등업 신청 방법은 사용자가 등업 신청을 하면 관리자가 수락할 때까지 신청 상태가 어떻게 되었는지 알 수가 없었다. 등업 신청이 수락되었는지 알수있는 방법도 자신의 등급이 신청한 등급으로 되어있으면 수락된 상태인 것을 알 수 있는 이상한 상태였다. 그래서 이 형태를 수정하기위해 생각해낸 방법은 등업 신청 게시판에서 자신의 등업 신청 현황이 보이게 하는 것이었다. 등업 신청 현황은 자신의 것만 보이게 하고 신청 상태를 3가지로 나눠봤다. 1. 진행중인(심사중) 상태 2. 신청 완료된 상태 3. 거절된 상태 등업 신청 게시판에 자신이 이전에 신청했던 기록도 모두 볼 수 있도록 신청이 거절되어도 해당 신청 글을 지우는 게..

원문보기 내부링크
Tistory

221128 TIL 사용자 등급을 위한 enum클래스

오늘 5번째 스프린트 회고를 끝냄으로써 남은 기간은 디자인 주를 한 주를 제외하면 일주일밖에 남지 않았다. 남은 일주일간 관리자 페이지를 만들어야 하기 때문에 오늘 관리자 등급을 어떻게 구현할 것인지에 대해 알아봤다. 우선 내 프로젝트의 경우 관리자 or 일반 사용자 등급이 두 가지로 나뉘는 게 아니라 사용자의 여러 가지 등급이 존재하도록 초반에 기획했었다. 각 사용자의 등급에 따라 접근할 수 있는 콘텐츠가 다르게 하기 위함이었다. 그래서 프로젝트 초반에 설계했던 객체 다이어그램을 보면 User Entity와 Grade Entity가 존재하고 Grade Entity는 User를 List로 갖는 형식으로 설계를 했었던 기록이 있다. 하지만 최근에 객체의 구조가 바뀌면서 Grade가 Entity일 필요가 없..

원문보기 내부링크
Tistory

221129 TIL 어드민에 대해 몰랐던 사실

오후에 동료분이 노아님께 어드민에 관련해서 여러 가지 질문을 하시는 것을 보고 마침 어드민 관련해서 고민하고 있던 터라 같이 듣다가 궁금했던 것 몇 가지를 물어보면서 오해하고 있던 사실과 몰랐던 정보를 얻을 수 있었다. 우선 어드민을 맨 처음 기획할 때 네이버 카페처럼 서비스를 이용하는 사용자가 어드민의 역할(카페 매니저)을 얻을 수 있는 형태로 어드민 계정을 따로 관리하려고 하지는 않았다. 사실 이때만 해도 어드민 계정 같은걸 이용해 본적이 없어서 어드민 계정을 따로 관리해야 한다는 개념을 몰랐었다. 그래서 그냥 네이버 카페처럼 사용자가 어드민의 역할을 부여받으면 어드민 계정이 되는 줄 알 있던 나... 이 무튼 노아님이 어드민 계정은 어드민 레파지토리를 만들어서 관리해주는 게 좋다고 말해주셨다. 컨트..

원문보기 내부링크
Tistory

221130 TIL 어드민이 등업 신청 관리하기

오늘은 사용자가 등업 게시판에 등업 신청 게시글을 올리면 관리자가 이를 확인하고 승인해주는 기능을 구현했다. 우선 사용자의 페이지에서 등업 신청 폼이 필요했다. 리액트의 Hook Form을 이용해서 신청 폼을 만들고 신청 폼에서는 신청 등급, 신청 사유를 적고 해당 정보들과 신청자의 닉네임을 백엔드로 post 요청한다. 이때 중복 신청을 방지하기 위해 이미 신청 중에 있는 사용자는 신청 못하게 해야 했다. 그래서 신청한 유저 닉네임으로 신청 게시글 레파지토리에서 신청한 게시글이 존재하는지 (existsByApplicant_Name) 확인 후 있으면 예외처리를 해주었다. 성공적으로 POST 요청된 신청 게시글은 어드민 페이지에서 게시글 리스트들을 확인할 수 있다. 관리자가 신청자의 정보를 확인하고 승인이 ..

원문보기 내부링크
Tistory

221125 TIL OAuth 2.0 알아보기

요즘 대부분의 웹/앱 서비스를 사용하면 필수로 만나게 되는 기능이 있다. 바로 해당 서비스의 사이트에 회원가입하지 않고도 다른 서비스의 계정을 가져와 사용할 수 있도록 하는 기능이다. 로그인을 하려고 하면 하단에 '카카오 계정으로 로그인', '네이버 계정으로 로그인' 등과 같이 버튼만 클릭하면 간편하게 로그인할 수 있는 기능을 쉽게 접할 수 있다. 오늘은 그 기능을 프로젝트에 적용하기 위해 방법들을 찾아봤다. 위와 같이 타 서비스의 계정을 사용해서 인증하는 방식을 OAuth 2.0 인증 방식이라고 한다. OAuth2.0 OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로써 사용되는, 접근 ..

원문보기 내부링크
Tistory

221126 TIL 게시판에서 원하는 게시물 찾기

오늘은 게시판 서비스에 없으면 불편한 기능인 검색 기능을 구현하려고 한다. 게시판에 검색기능이 없다고 생각해보자 만일 게시판에 게시글이 3, 4개 정도 있으면 찾으려는 게시물을 한눈에 찾을 수 있겠지만 게시물이 20, 30개만 돼도 찾으려는 게시물 하나를 찾기 위해서 2페이지 가서 찾고 3페이지 가서 찾는 과정이 필요하다. 사용자 입장에서 이는 매우 불편하기 때문에 게시판에서 검색기능은 필수라고 생각이 된다. JPA에서 검색 기능 검색을 하기 위해선 검색한 단어가 포함된 게시글들을 불러와야 하는데 JPA를 사용하면 편리하게 Repository의 메서드 이름으로 쿼리를 지정해서 찾을 수 있다. List posts = postRepository.findByTitleContaining(keyword); 위와 ..

원문보기 내부링크
Tistory

221127 TIL 검색 기능 구현 중 만난 문제 (pagination)

오늘은 어제 게시판 검색 기능을 간단하게 구현했던 것에 페이지네이션 기능까지 추가하려 하는데 발생한 문제와 해결 방법을 적어 보려 한다. 문제 상황 게시글 제목에 "검색"이라는 키워드가 포함된 게시물을 찾는데 총 11개가 존재할 경우 한 페이지에 10개가 출력이 돼야 하는데 9개만 출력이 되는 문제가 있었다. 근데 이 문제가 모든 게시물이 있는 전체 게시판에서는 발생하지 않는데 특정 카테고리의 게시물만 있는 게시판에서만 문제가 발생했었다. 왜 모든 게시물이 있는 전체 게시판에서는 정상적으로 10개씩 검색 결과가 출력되는데 특정 게시판에서만 10개가 아닌 9개만 출력이 되는지 의아했었다. 아래는 게시물을 search 하는 controller이다. 페이지 네이션을 위한 Pageable객체와 어떤 게시판인지 ..

원문보기 내부링크
Tistory

메가테라 22주차 주간회고 (프로젝트 6주차 회고)

22주 차 회고 (프로젝트 6주 차 회고) 메가 테라 22주 차를 진행하면서 있었던 일을 종합해서 회고하였습니다. 6주 차 작업 목표 6주 차의 목표를 세울 때 평소보다 더 타이트하게 잡았다. 그 이유는 디자인 주를 제외하고 프로젝트 마감까지 2주가 남았었는데 또 한 주는 관리자 페이지를 만들어야 했기 때문에 6주 차 동안에 사용자가 사용하는 기능은 모두 완성해야 했기 때문이다. 프로젝트 6주 차의 구체적인 작업 목표를 나열해봤다. 1. 마이 페이지(유저 정보 페이지)를 완성한다. 자신의 정보를 확인하고 수정할 수 있다.(닉네임, 프로필 사진) 마이 페이지에서 자신이 작성한 게시글, 댓글 수를 확인할 수 있다. 자신이 작성한 게시글, 댓글을 삭제할 수 있다. 자신이 좋아요를 누른 게시글을 확인 및 좋아요..

원문보기 내부링크
Tistory

221122 TIL 마이 페이지 구현하기

오늘의 작업 목표는 사용자 정보 페이지를 만드는 것으로 아래와 같은 화면을 만드는 것이었다. 해당 페이지의 url을 처음에는 /users/{Id}로 사용자의 아이디를 이용해 url을 구성하려고 했지만 생각해보니 다른 사용자의 아이디가 주소창에 공개되면 안 될 것 같다는 생각을 했다. 다른 서비스에서도 다른 사용자의 아이디를 전부 노출시키지 않고 아이디의 몇 글자만 보이고 나머지는 *으로 처리했던 게 생각이 났었다. 그래서 url은 /users? id={userId}으로 쿼리 스트링을 이용해 JPA에서 자동으로 부여해주는 id값으로 구성했다. 그리고 REST API는 GET /users/{userId}로 설계했다. 사용자 정보 페이지에서 필요한 정보는 아래와 같다. 1. 사용자가 작성한 게시글 리스트와 게..

원문보기 내부링크
Tistory

221123 TIL columnDefinition으로 기본값 설정

오늘은 마이페이지에서 자신이 작성한 게시글 또는 댓글을 삭제할 수 있게 삭제 버튼과 자신의 정보를 수정할 수 있는 수정 버튼이 필요했다. 근데 이 버튼들은 자신의 정보를 확인할 때만 이 버튼이 보이도록 설정을 해야 했다. 방법은 두가지 정도 떠올렸었는데 첫 번째로는 프론트엔드에서 로그인할 때 스토어에 로그인한 유저의 정보를 저장했기 때문에 사용자 페이지에 접속한 사용자의 아이디와 사용자 페이지에 접근해 백엔드에서 받아온 사용자의 정보가 같으면 버튼이 보이도록 하는 방법이 첫 번째로 생각해낸 방법이다. 두 번째 방법은 사용자 페이지에 접근할 때 local storage에 저장되어 있는 access token을 header에 전달해서 백엔드에서 전달받은 access token을 decode해 확인하려는 사용..

원문보기 내부링크
Tistory

221124 TIL axios.delete 요청 시 데이터 전달하기

오늘은 마이 페이지의 게시글 리스트에서 체크한 게시글을 삭제하는 기능을 구현했다. 처음에 작업 설계할 때 이 기능을 어떻게 구현해야 할지 전혀 감이 잡히지 않아 작업 설계하는데 어려움을 겪었다. 우선 delete 요청을 기존에 게시글 삭제할때 사용하던 api요청을 사용할지 새로 만들어서 새로운 api 요청을 사용할지 고민을 했었고 두 번째로 체크박스에 선택한 게시글의 아이디를 어떻게 저장하고 어떻게 지워야 할지 기능 구현에 대한 고민을 했었다. 우선 delete요청 하는 방법으로는 두 가지 방법을 생각했는데 그전에 체크한 게시글의 아이디를 저장하는 방법부터 정리해보자. 첫 번째로 체크한 게시글의 아이디를 저장할 배열을 useState로 만들어준다. 그리고 checkbox 타입인 input에 onChang..

원문보기 내부링크
Tistory

221119 TIL Grid와 친해지기

이번 주 월요일부터 사용자 스토리, 인수 테스트 재작성, 구조 재 설계로 인한 리팩터링 등등 다른 부가적인 작업들을 하느라 작업 진도를 전혀 못 나가고 있었다. 오늘 오후에 최종적으로 category가 하던 역할을 board가 하도록 위임해주는 작업을 마침으로써 다음 기능을 구현할 수 있게 되었다. 오늘 구현하려 했던 기능은 리그의 경기 일정을 확인하는 것이었다. 리그의 경기 일정은 rapid api를 사용해서 원하는 리그의 경기 일정을 모두 받아올 수 있다는 것을 이전에 확인했었다. RapidApi 사용법 : https://seungjjun.tistory.com/166 근데 param에 입력해준 시즌의 1년 동안 모든 리그의 일정을 받아와서 이미 경기가 끝나서 불필요한 경기 일정도 가져오는 문제가 있었..

원문보기 내부링크
Tistory

221120 TIL 지저분했던 코드 한줄로 해결하기

오늘은 경기 일정 페이지를 만들 때 해당 경기의 경기 시간을 보여줘야 하는데 api를 요청해서 받아오는 경기 시간이 영국 시간 기준(UTC)이라 한국 시간으로 계산(+9 시간)을 해줘야 하는 작업이 필요했다. 우선 받아오는 경기 시간의 데이터는 아래와 같다. 이 중 연도는 필요 없고 월, 일만 필요했기 때문에 substring으로 문자열을 잘라 14:00의 시간만 가져와서 시차 계산을 해주는 함수를 만들어서 화면에 보여주도록 했다. 시차 계산하는 함수는 UTC기준으로 가져오는 시간에 +9를 해주는데 24가 넘어가면 00:00부터 계산하는 로직을 작성했다. 위 사진과 같이 원하는 모양으로 만들고 11:00분이 잘 나오는지 테스트를 돌려보는데... 테스트가 통과가 되지 않는 문제가 있었다. 분명 화면에는 1..

원문보기 내부링크
Tistory

메가테라 21주차 주간회고 (프로젝트 5주차 회고)

21주 차 회고 (프로젝트 5주 차 회고) 메가 테라 21주 차를 진행하면서 있었던 일을 종합해서 회고하였습니다. 5주 차 작업 목표 프로젝트 5주 차의 구체적인 작업 목표를 나열해봤다. 1. 사용자 스토리를 As - I - So 구조로 수정하고 수정된 사용자 스토리를 바탕으로 인수 테스트 작성하기 2. 자신이 작성한 게시글, 댓글, 대댓글만 수정 또는 삭제할 수 있도록 로그인 기능 구현하기 3. 자신이 확인하고 싶은 리그의 경기 일정(오늘 경기, 선택한 날짜의 경기 일정)을 확인할 수 있게 한다. 4. 경기 시작 1시간 전 경기의 양 팀의 이전 기록과 전력을 비교할 수 있게 한다. 5. 사용자 정보 페이지를 구현해 해당 사용자가 작성한 글, 댓글을 확인할 수 있게 한다. 5주 차 작업 목표를 위와 같이..

원문보기 내부링크
Tistory

221121 TIL 의식적으로 기록하자

오늘은 5주차 스프린트 회의가 이루어졌다. 스프린트 회의를 진행하고 나서 노아님이 이야기하신 피드백을 떠올려보자. 우선 노아님이 가장 강조하신것은 작업을 진행하면서 작업 내용이나 배운점 느낀점들을 구체적으로 기록을 해야한다는 것이였다. 그런데 나의 문서에는 과정은 전혀 없고 결과에 대한 기록만 있고 구체적인 내용을 기록한게 없었다. 구체적인 작업 내용을 작업하면서 기록하지 않으면 나중에 필요할때 생각이 나지 않을 수 있기 때문에 힘들더라도 작업하면서 기록하는게 가장 좋다고 말씀해주셨다. 대표적인 예로 내가 구현한 채팅기능도 3일정도 공부하면서 구현을 했었는데 어떻게 구현했는지 어떤 내용들을 배웠었는지 구체적으로 기록을 남긴게 없었다. 이전에 채팅 기능 구현할때 TIL에 기록을 했었다고 생각했었는데 다시 ..

원문보기 내부링크
Tistory

221116 TIL 협력을 설계하자

오늘은 이전에 설계했던 객체가 잘못되었다는 것을 인지하고 객체지향의 사실과 오해를 참고해서 객체를 재설계해봤다. 객사오에서는 객체지향 설계의 첫 번째 목표를 훌륭한 객체를 설계하는 것이 아니라 훌륭한 협력을 설계하는 것이라고 강조하고 있었다. 협력을 설계한다는 것은 객체가 메시지를 선택하는 것이 아닌 메시지가 객체를 선택해야 한다는 것을 의미하기 때문에 메시지를 먼저 선택 후 메시지를 수신하기에 적절한 객체를 선택해야 한다고 한다. 솔직히 글만 봐서는 잘 와닿지 않았었다. 그래서 직접 내 프로젝트에 적용해봤다. 현재 게시판에서 설계하려는 협력은 게시글을 작성하는 것인데 메시지로 작성한다면 "게시글을 작성하라"이다. 객사오에서 나오는 방법처럼 화살표를 이용해서 설계해봤다. "게시글을 작성하라" 메시지 위에..

원문보기 내부링크
Tistory

221117 TIL 객체들로 구성된 작은 세상을 만들어 보자

어제 했던 협력 설계의 잘못된 부분을 감사하게도 아샬님께서 짚어주셨다. 어제 했던 협력 설계 인데 아샬님께서는 사용자에서 뭔가가 시작되었다는 건 의인화가 충분히 이뤄지지 않았다는 신호라고 말해주셨다. 사실 어제 혼자 설계하면서도 "게시물을 작성하라"메시지를 사용자부터 시작하면 게시물뿐만 아니라 다른 모든 것들도 다 사용자부터 시작하게 될 것 같은 느낌이 들어서 이게 맞나? 라는 생각이 들어 이상함을 느꼈었다. 아샬님께서 일반적인 게시판 서비스는 게시판이 “게시물을 작성해라”를 메시지를 받는다는 말을 해주셨다. 기존에 설계한 객체에서 게시판 객체가 존재하지 않았었는데 게시판 객체를 만들어서 객사오를 참조해 새롭게 처음부터 설계해봤다. 우선 게시판을 구성하는 요소들에 대해서 고민하는 것이 좋다고 책에 나와있..

원문보기 내부링크
Tistory

221118 TIL 게시판 객체를 생성해 리팩터링

어제 협력에 필요한 객체의 종류와 책임, 메시지를 정리했고 오늘은 설계한 것을 바탕으로 어떻게 리팩터링 할지 고민하는데 시간을 많이 사용했다. 우선 카테고리와 게시판 객체 사이의 관계가 애매했었는데 그 이유가 게시판의 이름이 카테고리 이름이랑 동일한 역할을 한다고 생각을 했다. 왜냐하면 카테고리는 어차피 축구라는 카테고리 안에 여러 개의 게시판이 존재할 것이기 때문에 카테고리 객체가 필요한가에 대한 생각을 하게 되었다. 그래서 동료들에게 카테고리와 게시판에 대한 관계(카테고리 안에 여러 개의 게시판, 게시판 안에 여러개의 게시물)를 설명하니 카테고리가 굳이 필요 없을 것 같다는 이야기를 해줬다. 그래서 기존에 카테고리가 하던 역할(카테고리에 맞는 게시글들을 프론트 엔드로 넘겨주는 것)을 게시판이 하도록 ..

원문보기 내부링크
Tistory

221113 TIL 댓글을 삭제했는데 대댓글은 왜?

댓글 삭제 기능 구현 중 대댓글과 관련된 이슈가 발생했다. 대댓글이 있는 댓글을 삭제하면 밑에 달려있던 대댓글까지 1+1 마냥 같이 삭제가 돼버리는 문제 발생한 것이다. 근데 데이터베이스를 확인해보니 댓글은 지워졌지만 대댓글은 지워지지 않았었다. 사실은 대댓글은 삭제가 된 것이 아니라 화면에 보이지 않는 것이었다. 왜냐하면 댓글이 있어야만 해당 댓글 밑에 대댓글이 보이게 해 놨기 때문이다. 댓글이 없어져 버리면 대댓글도 같이 없어져 버리는 기이한 현상이... 그래서 댓글을 삭제할 때 대댓글을 어떻게 처리해줄까 방법을 고민해봤다. 처음으로 생각해낸 방법은 댓글 삭제 시 대댓글이 있으면 대댓글이 존재하기 때문에 댓글을 삭제할 수 없다는 문구가 나오게 하는 것이었다. 두 번째 방법은 대댓글이 있는 경우에도 댓..

원문보기 내부링크
Tistory

221114 TIL 원칙을 위배해서는 안된다.

인수 테스트를 통해 검증하자 4주 차 스프린트 회고가 있었던 날이다. 노아님이 하나의 기능이 완성될 때마다 작성한 인수 테스트를 실행(codeceptJs)시켜 통과가 돼야 완성된 거라고 말씀을 하셨다. 그 말을 듣고 아차! 싶었다. 왜냐 나는 인수 테스트를 기획 문서에만 작성하고 작성한 인수 테스트를 코드로 옮기지 않았기 때문에 기능들을 구현해도 실행시킬 인수 테스트가 없었기 때문이다. 이는 완전히 잘못된 행동이었음을 깨닫게 되었다. 우선 노아님이 알려주신 올바른 프로젝트의 작업 순서는 아래와 같다. 1. 구현할 기능에 대해서 작성해 놓은 사용자 스토리를 바탕으로 기획 문서에 인수 테스트를 작성한다 2. 문서에 작성한 인수 테스트를 코드로 옮긴다. 3. 단위 테스트 코드를 작성하며 기능을 구현한다. 4...

원문보기 내부링크
Tistory

메가테라 20주차 주간회고 (프로젝트 4주차 회고)

20주 차 회고 메가 테라 20주 차를 진행하면서 있었던 일을 종합해서 회고하였습니다. 프로젝트 4주 차의 목표는 전체 게시판의 완성도를 높이고 게시판의 CRUD기능 구현하는 것과 월, 화에 아샬 님이 말씀해주신 내용을 바탕으로 controller와 service를 리팩터링 하는 것이 목표였다. 그래서 아래와 같이 작업 계획을 세웠고 작업에 대한 결과이다. 최종적으로 HOT 게시판 구현을 하지 못해서 계획했던 작업들을 모두 하지 못했기 때문에 계획한 작업을 다 하지 못한 이유에 대해서 회고를 해보려고 한다. 우연의 산물 이번 주 계획한 작업을 모두 달성하지 못한 첫 번째 이유는 컨트롤러와 서비스를 리팩터링 하는 부분에서 생각했던 것보다 수정해야 하는 부분들이 많아서 기존에 계획했던 스토리 포인트의 2배를..

원문보기 내부링크
Tistory

221115 TIL 인수테스트 하면서 만난 문제

오늘은 어제 작성한 사용자 스토리를 바탕으로 인수 테스트를 다시 작성하고 코드로 옮겨서 인수 테스트를 통해 지금까지 구현한 기능을 검증하기 시작했다. 우선 로그인 기능이 구현되지 않았기 때문에 로그인이 안되었을 때의 시나리오를 제외하고는 모두 테스트하는 와중에 막히는 테스트가 있었는데 게시글 작성할 때 게시글 제목이나 내용을 입력하지 않았을 때 나오는 팝업창의 문구가 제대로 나오는지 테스트하는 부분이었다. 제목은 입력하지 않고 카테고리 선택(selectOption), 내용 작성(fillField)을 하고 등록 버튼을 클릭(click)을 하도록 인수 테스트를 작성하고 ui화면으로 검사를 하는데 카테고리 선택하고 내용 입력하고 버튼도 잘 클릭해서 "제목을 입력해주세요"라는 팝업창이 뜨는 것까지는 확인했는데 ..

원문보기 내부링크
Tistory

221110 Pageable 사용해서 페이지네이션 구현하기

오늘은 게시판에서 게시글이 많을 때 게시판의 가독성적인 부분이나 정리된 화면을 위한 페이지네이션 기능을 구현했다. 페이지네이션(Pagination)이란? 게시판에서 모든 게시글을 한 화면에 모두 보여준 게 아니라 페이지를 나눠서 제공하는 것을 의미한다. 정렬 방식과 페이지의 크기, 그리고 몇 번째 페이지인지의 요청에 따라 정보를 전달해주는 것이 Pagination이다. 구현 목표 화면 한 화면에 게시글은 총 10개만 출력이 되고 넘어갈 시 다음 페이지 버튼이 생성된다. 한 화면에 보여주는 페이지 버튼은 총 10개(게시글 100개) 게시글이 100개가 넘어갈 시 다음 페이지(11페이지)로 이동할 수 있는 "다음"버튼이 생성된다. 만약 게시글이 100개가 존재하지 않는다면 다음 버튼은 생성되지 않는다. 11..

원문보기 내부링크
Tistory

221111 TIL useForm의 onChange (feat. register)

오늘은 게시글 수정 기능 구현하다 만난 문제와 해결방법을 적어보려고 한다. 우선 게시글을 수정할때 react-hook-form의 useForm을 이용해서 form을 생성해 수정된 게시글을 제출할 생각이였다. 수정할때 요구사항으로는 수정하려는 게시글의 제목과 내용을 수정할때 수정 폼에서 내용이 이미 입력된 상태여야 했다. 그래서 input태그 안에 value를 설정하고 value안에 기존에 갖고 있던 제목과 내용을 넣어줬다. 그리고 value값을 설정해주었기 때문에 입력할때 변화가 일어나게 하려면 input태그 안에 onChange를 넣어서 글자가 바뀌면 useState를 이용해 value값을 바꾸려고 했다. 그런데 아무리 입력해도 value값이 바뀌지 않고 변화하지 않는 문제가 발생했다. 처음에는 use..

원문보기 내부링크
Tistory

221112 TIL 바꿔야 할 것 같으면 바꾸자

오늘은 리팩터링은 필요하다고 느꼈을때 바로 해주는게 좋다는것을 깨달은 날이다. Post라는 게시글 세부 정보 컴포넌트를 만들면서 게시글에 필요한 정보들을 PostPage에서 Post 컴포넌트로 props를 전달해주는 구조였는데 props가 점점 쌓여 20개가 넘어가니까 리팩터링할때 엄청난 괴로움을 느꼈다. 현재 구조가 게시글 세부 페이지에 필요한 정보들을 post의 상위 컴포넌트인 PostPage에서 post의 상태를 관리하는 store를 이용해 상태들을 props로 내려주는 형태(PostPage -> Post)로 만들어져 있다. 그리고 게시글안에 댓글도 들어가는데 댓글은 별도의 컴포넌트로 만들어서 post안에 댓글 컴포넌트도 있기 때문에 최상위 컴포넌트인 PostPage에서 Post컴포넌트에 내려줘야하..

원문보기 내부링크
Tistory

221107 TIL 가치 중심의 사용자 스토리

월요일은 한주의 스프린트가 끝나는 날로 트레이너님과 스프린트 점검과 이번 주의 작업 계획을 다시 세우는 날이다. 저번 주와 다르게 이번 주는 채팅 기능 구현하는데 시간을 많이 소비해 구현해야 할 태스크들을 전부 끝내지 못한 상태라 찝찝함이 남아있는 상태로 스프린트 점검 시간을 기다리고 있었는데 아샬 님이 직접 내려오셔서 동료 한분이 쓰신 기획서를 모두 같이 보면서 피드백을 들었다. 그중에는 동료 한분에게만 국한되는 이야기가 아니라 프로젝트를 진행하고 있는 모두가 공감할만한 이야기와 알아두면 좋을 내용들도 너무 많이 이야기해주셨다. 기획서 작성할 때 가장 힘들었던 사용자 스토리 부분에 대해서 우선 말을 해주셨는데 가치 중심으로 썼다고 생각했던 나의 사용자 스토리가 정말로 가치 중심인지 다시 한번 생각하게 ..

원문보기 내부링크
Tistory

221108 TIL Value Object를 활용하자

오늘도 아샬 님이 오셔서 라이브 코딩을 하며 여러 가지 꿀팁을 전달해주시고 가는데 그중에서 오늘 내 코드에 적용한 것들만 정리해 봤다. Controller는 간단하게 Controller는 최대한 간단하게 만드는 게 좋다고 해주셨다. 그에 반해 나의 Controller는 상당히 복잡했다. 그 이유가 post라는 게시글에 전달해줘야 할 정보가 post객체뿐만 아니라 comment 같은 부가적인 객체들도 같이 전달해줘야 했기 때문에 여러 서비스를 호출해서 전달해줬는데 이것 때문에 복잡한 Controller가 만들어진 것이었다. controller를 최대한 간단하게 만들기 위해서 하나의 Action에서는 하나의 Application Service가 호출되어야 한다. 그래서 여러 개의 서비스를 불러서 전달해주던 ..

원문보기 내부링크
Tistory

221109 TIL 카테고리에 맞는 게시글 불러오기 (feat. 쿼리스트링)

오늘은 카테고리별 게시판을 만들어 봤다. 일단 카테고리별로 출력되는 게시글이 달라져야 했기 때문에 쿼리 스트링을 사용해서 카테고리의 아이디 값을 얻어와 카테고리에 포함된 모든 게시글들을 출력하도록 했다. localhost:8080/posts?category=1 여기서 (?category=1) 이 부분을 쿼리 스트링이라고 불린다. 그러면 위와 같은 path에서 쿼리만 가져오는건 어떻게 할 수 있을까?? useLocation 우선 useLocation을 사용해서 쿼리를 받아오는 방법을 알아보자. const location = useLocation(); useLocation을 이용해 location을 콘솔 창에 찍어보면 아래와 같은 결과가 나온다. 그중 search를 보면 우리가 원하는 정보인 쿼리("? ca..

원문보기 내부링크
Tistory

221104 TIL [Spring boot + React]실시간 채팅 기능 구현하기 - 2

어제 실시간 채팅 기능을 구현하기 위해 Http 방식보다는 WebSocket을 이용해서 구현하는게 더 효율적이라고 판단이되어 WebSocket을 이용해서 구현하기로 결정했다. 그런데 WebSocket을 사용하면 채팅방이 1개밖에 존재하지 못한다는 문제점이 있었다. 여러개의 채팅방이 필요했었기 때문에 WebSocket만으로는 내가 원하는 기능을 구현하지 못할것 같았다. 그래서 멀티 채팅방 기능을 구현할 수 있는 방법을 찾다 STOMP라는 것을 알게되었다. STOMP는 pub/sub패턴을 사용하기 때문에 멀티 채팅방을 구현할 수 있다는 것을 알게되었다. STOMP STOMP(Simple Text Oriented Messaging Protocol)는 메시지의 형식, 유형, 내용 등을 정의하여 메시징 전송을 효..

원문보기 내부링크
Tistory

221105 TIL [Spring boot + React]실시간 채팅 기능 구현하기 - 3 (with STOMP)

채팅 기능을 아직 구현하지는 못했지만 오늘 배우고 이해한 STOMP에 대해서 정리해보려고 한다. STOMP를 사용하게 되면 text와 binary 두가지 유형의 메시지만 정의하는게 아니라 규격을 갖춘 메시지를 전달할 수 있다. COMMAND header1:value1 header2:value2 Body^@ COMMAND : SEND, SUBSCRIBE를 지시할 수 있다. header : WebSocket만으로는 표현이 불가능한 header를 작성할 수 있다. destination: 이 헤더로 메시지를 보내거나 구독을 할 수 있다. (pub/sub 구현) 예를 들어 아래 코드와 같이 유저A는 3번 채팅방을 구독할 수 있다. SUBSCRIBE destination: /subscribe/chat/room/3 ..

원문보기 내부링크
Tistory

221106 TIL [Spring boot + React]실시간 채팅 기능 구현하기 - 4

오늘 드디어 Spring + React를 이용해서 실시간 채팅 기능을 구현했다. WebSocket으로 채팅방 하나인 1:1 채팅 기능은 구글링 조금만 하면 금방 구현할 수 있었는데 채팅방이 여러 개를 구현하기 위해 STOMP를 사용해야 할 때부터 막히기 시작했었다. 구글링 하면 정보는 많았지만 STOMP를 전혀 알지 못한 채 알아보려니까 이게 맞는 정보인지 틀린 정보인지 판별이 되지 않아 하나씩 전부 읽어보면서 확인하는 작업을 하는데 너무 오랜 시간이 걸렸다... ㅠㅠ 솔직히 실시간 채팅 하나 구현하는데 4일이나 걸릴 줄은 몰랐지만 포기하지 않고 어떻게든 구현했다는 사실과 채팅을 구현하는데 최적의 코드는 아닐지라도 이것저것 해보면서 실시간 채팅을 구현했다는 사실만으로도 너무 기뻤다. 아무튼 어제는 Spr..

원문보기 내부링크
Tistory

메가테라 19주차 주간회고 (프로젝트 3주차 회고)

19주 차 회고 메가 테라 19주 차를 진행하면서 있었던 일을 종합해서 회고하였습니다. 리팩터링의 연속 이번 주는 객체 구조를 바꾸는 데 시간을 너무 많이 사용했다. 실제로 주중에 2번을 바꾸면서 좋아요 기능과 댓글 기능을 구현하는데 예상했던 스토리 포인트를 객체 구조를 바꾸는 데 사용을 해서 예상했던 것보다 오버되기도 했다. 모양이 이상하긴 한데 맨 처음 객체를 설계할 때 작성했던 것이다. post라는 게시글이 담고 있어야 할 정보들의 연관관계를 @ManyToOne과 @OneToMany 어노테이션을 이용해 매핑했었는데 이 방식 말고 한 객체 안에서 다른 객체의 정보를 들고 있지 않고 자신이 갖고 있어야 할 갖고 기존에 갖고 있던 다른 객체들의 정보는 아이디 값만 갖는 방식으로 구조를 다시 바꿨다. po..

원문보기 내부링크
Tistory

221101 TIL JPA 양방향 연관관계 Infinite recursion문제

오늘은 어제 학습한 @ManyToOne과 @OneToMany를 활용해서 Entity들을 설계한 대로 객체를 매핑을 하는 작업을 했다. 기존의 모델들을 변경하고 새로만들고 하다 보니까 작성했던 테스트 코드나 프론트엔드에서 값을 전달해주는 방식, 테스트 코드 등 모든 게 바뀌어야 했다. 그래서 오늘 리팩터링 하는데만 스토리 포인트 5를 사용해버렸다.. 모델 설계를 초반에 하고 했어야 했는데 생각없이 첫 주차에 게시글 보기와 작성하는 기능을 만든다고 임시방편으로 만들었던 모델이 오늘 모델들을 다시 설계한 대로 바꾸면서 발생한 문제들을 해결하는 것과 변경해야 하는 코드들이 너무 많아 고통으로 돌아왔다. 작업설계의 중요성.. @JsonManagedReference @JsonBackReferenc @ManyToOn..

원문보기 내부링크
Tistory

221102 TIL JPA n + 1문제란

모델 설계 관련 이야기를 하던 중 어제 객체 연관 관계를 설정해줄 때 사용한 @ManyToOne, @OneToMany어노테이션을 사용할 때 문제점으로 n + 1 문제를 말해주셨다. n + 1 문제는 무조건 알고 있는 게 좋다고 하셨고 JPA를 사용한다면 알고 있어야 한다고 말하셨다/ 내가 원치 않아도 n + 1 문제를 만날 수 있고 이는 성능에 영향을 줄 수 있기 때문에 n + 1문제는 알고있자 N + 1 문제란? n + 1문제는 엔티티를 조회할 때 1번 조회해야 할 것을 연관 관계가 설정된 N개 종류의 데이터 각각을 추가로 조회하게 돼서 총 N+1번 조회를 하게 되는 문제이다. 예시로 게시글과 댓글을 @ManyToOne, @OneToMany를 이용해 연관 관계를 설정한 Entity 코드이다. Post...

원문보기 내부링크
Tistory

221103 TIL [Spring boot + React]실시간 채팅 기능 구현하기 - 1

축구 커뮤니티 사이트의 기능 중 하나인 실제 경기가 진행되는 시간에 채팅방이 열려 실시간으로 응원할 수 있는 기능을 구현하기 위해 실시간 채팅 기능을 구현하고자 한다. 아래 화면은 whimsical 디자인 툴을 이용해서 디자인한 화면인데 이 화면에서 가장 핵심은 실시간 응원인 실시간 채팅 기능이다. 그래서 오늘 짧게나마 실시간 채팅 구현 방법을 공부해 봤다. 우선 실시간으로 채팅을 구현하는 방법으로는 HTTP와 WebSoket 방법이 존재한다. HTTP의 특징 http통신의 특징부터 알아보자 http 통신은 단방향(비연결성)이다. 클라이언트가 보낸 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어 버리는 비연결성 성질 request - response 구조이다. 서로 지속적으로 연결되어 있는 형태가 ..

원문보기 내부링크
Tistory

221029 TIL 게시판 조회수 기능 구현하기

게시글 상세 페이지 구현중 보여야 하는 정보들을 나열해 보는데 게시글의 조회수가 필요했기 때문에 조회수 기능을 구현해보기로 했다. 처음에는 조회수 기능을 어떻게 구현해야 하지 막막했었는데 생각보다 간단하게 구현할 수 있었다. 조회수 기능 구현 과정 1. Post Entity 조회수를 위한 hit를 Long 타입으로 설정해주었다. 처음에는 조회수를 나타내는 건 자연수이기 때문에 int타입을 사용했었는데 생각해보니 id값도 자연수인데 Long타입을 사용하고 있었다. 원시 타입이 아닌 참조 타입을 사용하는 이유는 null값을 담기 위해서이다. 원시 타입인 int를 사용하면 값이 없을 때 0이 설정된다. 반면에 참조 타입인 Long은 값이 없으면 null을 담는다. 만일 값이 없을 때 0을 담게 되면 값이 들어..

원문보기 내부링크
Tistory

221030 TIL Spring Boot AWS S3 연동해서 파일 업로드 하기 (S3 Bucket 생성부터 연동까지)

이번 주 스프린트의 핵심 게시글 작성할 때 이미지 업로드하는 기능을 오늘 구현했다. 어제 AWS 가입이 되지 않아 S3를 이용해 이미지를 업로드하는 것을 포기하려 했지만 오늘 일어나서 메일함을 보니 어제 그렇게 기다리던 가입 완료 메일이 새벽 5시에 정상적으로 도착한 것을 확인할 수 있었다. S3를 이용해서 이미지 업로드할 수 있다는 기쁨을 느꼈다. (이미지 업로드를 위해 수많은 삽질을 할 나의 미래를 모른 채..) 게시글에 이미지 업로드를 위한 spring에 AWS S3 연동방법 1. AWS S3 버킷 생성하기 S3 서비스로 이동 후 버킷 만들기로 이동한다. 그다음 버킷 이름(소문자)을 입력한다. 모든 퍼블릭 액세스 차단 체크를 풀어준 다음 밑에 두 개만 다시 체크해준다. 첫 번째 새 ACL(액세스 제..

원문보기 내부링크
Tistory

메가테라 18주차 주간회고 (프로젝트 2주차 회고)

18주 차 회고 메가 테라 18주 차를 진행하면서 있었던 일을 종합해서 회고하였습니다. 기획 끝 개발 시작 이번 주 월요일 시작은 저번 주 개발한 것을 바탕으로 깃허브의 프로젝트를 이용해 칸반 보드를 만들어 백로그를 쭉 작성했다. 사용자 스토리를 적고 그 사용자 스토리를 구현하기 위한 task들을 적어서 백로그 목록을 만들어 체계적으로 개발하는 방법을 배웠다. 이번 주에 실제로 깃허브 프로젝트에서 작성한 칸반 보드를 이용해 개발한 흔적 이번 주에 목표로 잡았던 개발 기능과 개발 시작 전 스토리 포인트 매겼던 것과 실제로 사용한 스토리 포인트 결과이다. 목표했던 기능들은 모두 구현했지만 스토리 포인트에서 어느 정도 오차가 났다. (그래도 생각보다 큰 차이가 나지 않았다.) 3포인트 정도 오차가 났는데 차이..

원문보기 내부링크
Tistory

221031 TIL @OneToMany, @ManyToOne (feat. mappedby)

오늘은 게시판 객체 간의 구조 설계를 위해 @ManyToOne과 @OneToMany에 대해서 공부했다. 현재 진행 중인 게시판 프로젝트를 예시로 User(사용자)가 1개 이상의 Post(게시글)을 작성할 수 있기 때문에 아래처럼 테이블 구조를 설계했다. 우선 간단하게 OneToMany와 ManyToOne을 먼저 맛보면 아래 구조에서 User 입장에서는 @OneToMany이고 Post입장에서는 @ManyToOne이다. 우선 두 객체를 연결하기 위해서 Pos 객체에 User 객체를 만들고, User 객체에는 User가 쓴 글 모두를 담을 수 있는 List타입의 posts를 만들었다. Post객체에 User에는 @ManyToOne 붙여주고 User객체에 Post List에는 @OneToMany를 붙여주었다. ..

원문보기 내부링크
Tistory

221026 TIL KiCK OFF

어제 피드백을 받고 수정한 기획안을 바탕으로 다음 스프린트(다음 주 월)까지 구현해야 할 기능 리스트와 얼마 큼의 시간을 투자하고 구현할 수 있는지 스토리 포인트를 매겨보는 시간을 가졌다. 다음 주 스프린트까지 구현해야 할 기능을 정하는데 내 서비스 중에서 가장 핵심 기능부터 구현해야 했다. 그래서 커뮤니티 서비스의 핵심이 게시글을 읽고 쓰는 것이라 생각해서 게시물을 읽는 것을 가장 먼저 구현해야 할 기능으로 잡았다. 그리고 해당 기능의 스토리 포인트 점수를 매기는데 스토리 포인트 점수를 매기는 기준을 1 뽀모(40분/10분/10분)를 이용해서 잡았는데 생각보다 기능 하나를 구현할 때 몇 뽀모가 필요한지 측정하기가 쉽지 않았다. 기능 하나를 대강 기준을 잡고 그 기준을 이용해 다른 기능들을 구현하는데 상..

원문보기 내부링크
Tistory

221027 TIL 게시글 출력하기 (feat. SQL 예약어 Like)

작업설계 어제 프론트엔드 세팅을 끝냈기 때문에 오늘 시작을 백엔드를 세팅하는 작업으로 하루를 시작했다. 작업을 시작하기 전에 설계를 먼저 하는 원칙이 있었기 때문에 세팅하는 작업도 먼저 간단하게 설계(?) 아닌 설계를 먼저 해봤다. 우선 기본적으로 강의에서 배웠던 것을 떠올리며 7가지 dependencies를 추가해주고 스프링이 제공해주는 security도 사용하지 않을 거라 로그인 폼을 막는 세팅도 해줘야 한다. 아무튼 백엔드 세팅을 스토리 포인트로 2 뽀모로 잡았는데 1뽀모하고 조금 지나서 기본 세팅을 다 끝낼 수 있었다. 이제 본격적인 작업이 시작하는데 맨 처음 구현해야 할 기능이 전체 게시판(홈 화면)을 읽을 수 있도록 하는 것이었다. 역시 이 작업도 시작하기 전에 설계를 먼저 했다. 일단 전체 ..

원문보기 내부링크
Tistory

221028 TIL REST API URI설계

오늘은 글 작성 기능 구현을 목표로 작업 설계를 시작했다. 글 쓰기에 대한 인수 테스트 작성부터 하고 useForm을 이용해서 글 작성 폼을 만드는 것을 먼저 하는 것으로 순서를 잡았다. 글 작성시작성 시 기본적으로 필요한 내용으로는 글 제목, 글 내용, 카테고리 선택 그리고 사진은 선택사항으로 계획했고 글 작성 페이지의 URI는 write로 정했다. 그래서 REST API 설계 시에도 게시글 작성 시 URI를 POST /write로 정했었다. 그런데 REST API 설계 시에 규칙이 있다는 것을 알게 되었고, 내가 사용한 write가 동사형태라 설계 규칙에 위반되었기 때문에 /post로 바꿔야 했다. REST API URI설계시 유의할 점 URI는 정보의 resource(자원)를 표현해야 한다. 1. ..

원문보기 내부링크
Tistory

메가테라 17주차 주간회고 (프로젝트 1주차 회고)

17주 차 회고 메가 테라 17주 차를 진행하면서 있었던 일을 종합해서 회고하였습니다. 새로운 시작 이번 주는 16주간 메타버스 공간인 zep에서의 온라인 교육을 마치고 성수 코딩 도장에서 2달간 프로젝트를 진행하기로 되었다. 온라인 교육을 받으면서 오프라인 교육에 대한 기대감을 갖고 있었기 때문에 성수 확실히 집에서 온라인으로 교육을 받는것 보다 오프라인으로 하는 게 집중하는 시간이 차이가 났고, 특히 더 좋았던 건 트레이너님이 매우 가까이 있으니까 아주 빠르게 피드백을 받을 수 있어서 좋았다. 그리고 기존에 만났던 동료들도 있지만 온라인으로만 만나던 동료들도 직접 보면서 다같이 한 장소에 모여서 공부를 하니까 한 주간 즐겁게 공부를 할 수 있었던 것 같았다. 하지만 아침 출근시간에 지하철을 타야해서 ..

원문보기 내부링크
Tistory

221023 TIL 디자인툴 사용해서 속도 높이기

오늘은 손으로 그리던 UI를 빠른 작업을 위해 관리자 페이지는 피그마를 이용해서 그려봤다. 피그마라는 디자인 툴을 이용해 본적이 없어서 처음에 거부감이 들어 종이에 손으로 그렸었는데 동료들이 디자인 툴을 사용하는 걸 보고 접근성이 나쁘지 않다는 것을 뒤늦게 알게 되었다. 직접 사용해보니 간단한 기능들은 그림판 사용하듯이 쉽게 사용할 수 있었고, 손으로 그리면서 작업했던 시간보다 훨씬 빠르게 작업할 수 있었다. 진작에 디자인툴을 이용했으면 어땠을까 하는 후회를.. 하지만 허접한 그림실력으로 직접 손으로 그리는 감성도 나쁘지많은 않았다.. 카페 운영 화면 카페를 기본적으로 운영할때 필요한 기능들이 있는 화면이다. 가입 방식이나 멤버 목록의 공개 여부를 설정할 수 있고 가입을 몇 번째로 했는지와 같은 이벤트도..

원문보기 내부링크
Tistory

221024 TIL 칸반 보드와 테스크 테이블

오늘은 저번 주 한 주 동안 기획한 결과물을 공유하며 노아님에게 피드백받는 시간과 진짜 개발을 시작하기 위한 백로그 작성하는 방법을 배웠다. 우선 사용자 스토리가 가치 중심으로 작성이 되어야 하는데 나는 너무 포괄적인 스토리를 작성해 지적을 받았다. 빠르게 사용자가 특정 행위를 함으로써 얻을 수 있는 가치를 생각을 해보면서 사용자 스토리를 다시 작성했다. 그리고 백로그 작성은 Jira라는 프로그램을 공유가 되지 않는 이유로 이용하지 못해 깃허브 프로젝트를 이용하여 최대한 비슷하게 틀을 만들고 사용자 스토리를 바탕으로 테스크 테이블에 사용자 스토리와 백로그를 하나씩 작성하는 방법을 배웠다. 위 사진은 "관리자는 카페를 운영하기 위해 특정 멤버에게 스탭 역할을 부여 또는 해임할 수 있다."라는 사용자 스토리..

원문보기 내부링크
Tistory

221025 TIL 무료 api를 이용해서 데이터 가져오기(feat. RapidAPI)

오늘은 어제 작성한 사용자 스토리와 태스크들을 피드백을 받았다. 사용자 스토리는 잘 작성했는데 태스크는 태스크를 보고 개발을 단계별로 진행할 수 있는 상태가 되야하는데 내가 쓴 태스크는 너무 포괄적이라서 더 세분화 되어야 할 필요가 있다고 해주셨다. 그리고 구현해야할 기능 중 채팅 기능이 있었는데 그냥 상대방과 1:1로 채팅을 하는게 전부인 기능이라 채팅을 하는 목적이 없다는 피드백을 받았다. 그래서 실시간 채팅을 이용해서 실제 축구 경기가 진행되고 있을때 실시간으로 응원 메시지를 남길 수 있는 기능을 만들기로 했다. 아래와 같은 페이지 처럼 구현이 될것 같은데 그러기 위해서는 채팅 기능 뿐만 아니라 해당 경기에 대한 데이터가 필요했었다. 프리미어리그의 경기 일정이나 정보를 얻어오는 방법에 대해서 알아봤..

원문보기 내부링크
Tistory

221020 TIL 무엇 하나 쉬운게 없는 하루(feat. JadenCase 문자열 만들기)

이번 주의 핵심은 프로젝트 기획이지만 오늘은 코딩 도장 시간에 자바스크립트로 풀지 못한 JadenCase문자열 만들기 문제에 대해 글을 쓰려고 한다. 사실 어제 자바로 풀었던 문제라서 오늘은 금방 풀겠지 생각을 하고 어제 풀었던 방법과 다르게 풀려고 시도를 했는데 결국 1시간 내에 풀지 못했다. 다른 동료들은 모두 제 시간에 푼 것 같았는데 혼자 풀지 못해서 저녁 먹고 나서 다시 코딩 도장 문제에 도전을 했다. 어제는 자바에서 split을 사용해 공백을 기준으로 나눠 푸는 방법을 사용했었는데 공백이 연속일 때의 조건을 생각하지 못해 애를 먹어서 오늘은 split을 사용하지 않고 풀 수 있는 방법을 모색했다. 문자열의 맨 처음 단어가 대문자이고 모든 단어는 서문자로 변환해야하는 문제였다. 일차적으로 한문자..

원문보기 내부링크
Tistory

221021 TIL 더 구체적으로 기획하기

오늘은 어제 노아님이 기획 프로세스의 예시를 보여주시면서 기획을 어떻게 해야 하는지 큰 틀을 알려주셨다. 처음 해보는 기획이라 어떻게 해야 할지 갈팡질팡 하면서 무엇하나 제대로 되지 않고 진도도 나가지 않는 느낌을 많이 받고 있었는데 어제 설명을 딱 듣고 나니 당장 뭘 해야 할지 명확해졌었다. 그리고 지금까지 했던 기획을 살펴보니 지금까지 기획한 내용이 부족하다는 느낌과 너무 구체적이지 못하다는 것을 깨닫고 다시 UI 프로토 타입을 큰 종이에 그리기 시작했다. Mobile First 디자인을 하기 위해 우선 모바일 기준으로 UI를 그려나갔다. 커뮤니티 사이트를 만들어야 해서 사용자 페이지와 관리자 페이지를 만들어야 했는데 오늘은 사용자가 볼 수 있는 UI를 먼저 작성했다. 좌 전체 게시판 화면 / 우 메..

원문보기 내부링크
Tistory

221022 TIL 관리자 프로세스 구조도 만들기

항상 주말마다 집 앞에 있는 카페에 가서 공부를 했었는데 오늘은 조금 귀찮더라도 성수 코딩 도장에서 어제 못다 한 관리자 페이지 UI와 프로세스 구조도를 작성하기로 마음먹고 출발했다. 좌 관리 홈 화면 / 우 멤버 스탭 화면 관리자 페이지를 그려보는데 처음에 생각했던 사이즈보다 안에 들어가야 할 내용들이 훨씬 많은데 자리가 없어 그리지 못했다. 그리고 손으로 직접 UI를 그리려고 하니까 생각했던 작업 시간보다 더 오래 걸리고 반복되는 디자인도 있어서 아무래도 관리자 페이지는 디자인 툴을 이용해서 작업해야 할 것 같다. 관리자 프로세스 구조도 그리고 오늘은 웹 프로세스 구조도를 그려봤다. 사용자의 프로세스와 관리자의 프로세스가 있어 한 번에 다 그리기에는 복잡해져서 그리기 어려울 것 같아 두 개를 나눠서 ..

원문보기 내부링크
Tistory

메가테라 16주차 주간회고

16주 차 회고 메가 테라 16주 차를 진행하면서 있었던 일을 종합해서 회고하였습니다. 이번 주는 지난주에 대부분의 기능은 구현했기 때문에 디테일적인 부분과 전체적인 완성도를 높이는데 집중을 했던 것 같다. 특히 테스트 코드를 작성하는데 시간을 대부분 할애한 것 같은데 그 이유는 모킹에 대한 어려움을 겪었었기 때문이다. 강의에서 배운 대로 따라 해도 혼자 하면 생각보다 쉽지 않아서 모킹 하는 방법을 익히는데 시간을 많이 들였다. 근데 모킹을 하지 않아도 테스트가 가능하다는 것을 뒤늦게 깨달았다. 모킹 때문에 테스트 코드 작성이 어려우면 설계가 잘못되었을 가능성이 높다는 아샬님의 영상을 보고 컴포넌트 구조를 살짝 바꿨는데 모킹 없이 쉽게 테스트할 수가 있었다. page 컴포넌트에서 필요한 것들을 불러와 하..

원문보기 내부링크
Tistory

221017 TIL 만들고 싶은걸 만들자 (돌돌축)

프로젝트 기획 3일 차에 드디어 어떤 주제로 프로젝트를 진행할지 정해졌다. 사실 어제 결정했던 당근 마켓의 기능에 실시간 경매 기능을 더한 서비스로 진행하려 했었지만 오늘 성수 코딩 도장에 와서 기획하던 중 동료 한 분이 그래도 2달간 진행하는 건데 본인이 재밌고 관심 있는 걸로 진행하는 게 좋지 않겠냐는 말과 아이디어를 몇 개 던져주셔서 축구 관련 커뮤니티를 다시 하기로 마음을 먹었다. 돌고 돌아 축구로.. 노아님께서 축구 커뮤니티를 만들 거면 게시판이 팀별로 존재하고 그 팀 안의 선수별로도 게시판이 존재해서 선수가 이적하면 그 선수 게시판은 사라지고 누군가 새로 오면 새로운 선수의 게시판이 새로 생기는 식의 동적인 게시판 정도는 만들어야 한다고 말씀해주셨다. 그런 복잡도를 가진 게시판의 대표적인 예로..

원문보기 내부링크
Tistory

221018 TIL PHP 탐구하기

웹페이지를 만들기 위해서는 어떤 언어를 사용해야 하는지 검색을 해보면 대표적으로 PHP가 나온다. 프로그래밍을 처음에 시작할 때 아무것도 모르던 시절에 PHP를 어디선가 얼핏 들어본 것 같은 기억이 있는데 그 PHP를 오늘 알아봤다. PHP(Hypertext Preprocessor) PHP는 대표적인 서버 사이드 스크립트 언어로 웹 개발에 적합하며 HTML에 내장될 수 있는 언어이다. 여기서 말하는 서버 사이드 스크립트 언어는 웹에서 사용되는 스크립트 언어 중 서버 사이드에서 실행되는 스크립트 언어(컴파일이 필요가 없는)를 말한다. PHP는 동적인 홈페이지를 만들기 위해 설계 되었고 Html안에 코드가 포함되어 다른 개발언어보다 빠른 개발 속도를 보여줄 수 있다. PHP코드 예제 그리고 동적 언어이기 때..

원문보기 내부링크
Tistory

221019 TIL Python의 Django

2022년 10월 TIOBE Index사이트 기준 프로그래밍 언어 순위 1등인 python의 웹 프레임워크인 Django에 대해 알아봤다. 어떤 언어로 웹 사이트 개발을 해야 할지 검색을 해보면 python이 빠지는 곳이 없을 정도로 인기가 많다. 그리고 개발자가 맨 처음 작성하는 코드인 Hello, world를 나는 파이썬으로 작성했다. python을 학교 동아리에서 잠깐 배운적이 있어 정말 새로운 언어는 아니지만 이미 자바에 지배된 몸이라 python은 잊혀진지 오래다. Python python은 객체 지향 프로그래밍 언어이다. 그리고 인터프리터 언어이며 변수의 타입을 지정해주지 않아도 되는 동적언어이다. 인터프리터란, 프로그래밍 언어의 소스 코드를 바로 실행하는 컴퓨터 프로그램 또는 환경을 말합니다..

원문보기 내부링크
Tistory

221012 TIL 내 서비스는 믿을만한가?

오늘도 테스트 코드를 열심히 작성하던 중 초반에 비해 생각보다 테스트 코드를 많이 작성했다고 생각했었는데 동료의 테스트 코드 개수를 들어보니 다 작성하지 않았는데도 50개가 넘는다고 하셨다.. 잉??? 난 테스트를 다 작성한 것 같은데도 30개가 겨우 넘었는데 50개나..?? 분명 같은 웹페이지를 만드는데 테스트 케이스가 한 두개 차이가 아니라 무려 20개가 넘게 차이가 난다는 건 내가 빼먹고 하지 않은 테스트들이 존재한다는 거고 그 말은 테스트로 검증된 서비스가 아닌데도 완성되었다고 착각하고 있었다는 소리다. 그래서 다시 작성하지 않은 테스트들이 있는지 확인을 하는데 역시나 예외 케이스에 대한 테스트나 초반에 모킹에 대한 어려움 때문에 하지 않았던 테스트들이 존재한 것을 확인했다. 우선 예외케이스에 대..

원문보기 내부링크
Tistory

221013 TIL @RequestBody vs @ModelAttribute

@ModelAttribute 어노테이션에 대해 알아보던 중 @ModelAttribute도 @RequestBody와 같이 client에서 보낸 데이터를 자바 객체로 변환시켜서 자바에서 사용할 수 있게 만드는 역할을 한다는 것을 알게 되었다. 똑같은 역할을 하는 것 같은데 어느 경우에는 @ModelAttribute를 쓰고 어떤 경우에는 @RequestBody를 사용하는지 궁금해졌다. 그래서 @ModelAttribute와 @RequestBody와의 차이점을 알아봤다. @ModelAttribute @ModelAttribute 어노테이션은 client가 보내는 HTTP parameter를 자바 객체에 바인딩하는 역할을 한다. form형태의 데이터나 url뒤에 붙어서 오는 쿼리 스트링 형태(/user? name=j..

원문보기 내부링크
Tistory

221014 TIL 테스트기간동안 키운 메타인지 능력

길다면 길고 짧다면 짧았던 2주간의 레벨테스트가 드디어 끝났다. 이전 8주 차 당시 3주 차로 이월을 크게 하고 나니까 이번 레벨테스트를 시작하기 전부터 레벨테스트에 대한 부담감은 가중되어 있는 상태였다. 이전과 똑같은 실수를 반복하고 싶지 않아 열심히 하는 것은 물론이고 내가 개발에서 사용하는 코드 중 모르는 게 나오면 직접 찾아보고 정리하면서 실험도 해보는 힘들지만 재미있었던 레벨테스트 기간이었다. 레벨테스트가 끝나고 이제는 개인 프로젝트에 들어간다는 말을 들었을 때는 왠지 모를 설렘 반 두려움 반이었다. 레벨테스트를 진행하면서 내 실력이 어느 정도인지 대강 짐작을 하고 있기 때문에 이 실력으로 개인 프로젝트를 잘 만들 수 있을까? 하는 두려움이 있었다. 하지만 테스트 기간 동안 느낀 건데 서비스 같..

원문보기 내부링크
Tistory

메가테라 15주차 회고

15주 차 회고 메가 테라 15주 차를 진행하면서 있었던 일을 종합해서 회고하였습니다. 15주 차는 레벨테스트가 진행이 되었다. 이번 레벨 테스트는 2주간 진행되기 때문에 아직 레벨테스트가 끝나지 않았다. 이번 테스트의 주제는 "마카오 기프트"라는 쇼핑몰을 만드는 것이었다. 지난주차에 총복습을 하면서 만들었던 마카오 뱅크 서비스와 크게 다르다고 느끼지는 않아서 처음부터 막 이거 어떻게 만들어야 하지?라는 생각은 하지 않았다. 다만 저번 주에는 솔직히 테스트 코드나 문서작성 등 마카오 뱅크 웹페이지를 구현하는 것 이외에 다른 작업들을 조금 소홀히 했다면 이번 주는 2주간 진행되기 때문에 완성을 목표로 하되 다른 해야 할 것들도 놓치지 않고 진행하려 했다. 그러다 보니까 리액트에서 테스트를 위해 모킹 하는 ..

원문보기 내부링크
Tistory

221009 TIL 로그인이 된 줄 알았지..

오늘은 아직 구현하지 못한 로그인과 회원가입 기능 구현을 목표로 시작했다. 로그인과 회원가입 기능을 맨 마지막에 구현하는 이유는 아샬 님이 맨 마지막에 인증 / 인가 처리하시기 때문에 작업의 흐름을 따라 하려는 것도 있지만 서비스에서 로그인 회원가입이 중요한 기능은 아니라고 판단이 되었고, 로그인 회원가입을 먼저 구현하면 내가 만든 서비스를 테스트용으로 이용할 때마다 로그인해서 이용해야 하는 번거로움이 있을 것 같아 제일 후순위로 밀어놓았다. 로그인을 구현하던 중 이제는 안만나면 섭섭한 친구인 오류를 마주했는데 오늘도 꽤나 애를 먹었다. 로그인이 당연히 데이터베이스안에 있는 아이디로만 로그인했을 때 로그인이 돼야 하는데 데이터베이스에 존재하지 않는 아이디로 로그인을 해도 로그인이 되는 이상한 상황이 되어..

원문보기 내부링크
Tistory

221010 TIL 자바스크립트 실력 높이기

리액트를 하다가 보면 자바스크립트 문법을 틀려서 오류를 접하는 경우가 많다. 얼마 전에만 해도 객체로 리턴하는 값을 배열로 받으려고 했던 것과 push메서드를 사용해서 원본 배열을 변경해 발생한 오류 등등 여러 가지 자바스크립트 사용이 미숙해서 낭패를 겪은 적이 몇 번 있다. 그래서 이런 상황을 하루빨리 극복하기 위해 야심 차게 준비한 책이 있다. 얼마 전에 홀맨님이 2기분들에게 추천해준 자바스크립트 책인데 아무래도 나도 사서 공부해야 할 필요가 있어서 구매를 했다. 2장까지 읽은 상황인데 원래 책을 빠르게 읽지 못하는데 이 책은 생각보다 빠르게 읽고 있다. 며칠 전에 공부했던 호이 스팅이라는 개념도 나오고 원본 배열을 조작하면 안 되는 이유, 그리고 모르고 있었던 것들도 꽤나 있어서 재미가 있는 것 같..

원문보기 내부링크
Tistory

221011 TIL 사소하지만 중요한 차이

백엔드에서 회원가입 유효성 검사를 진행하기 위해 테스트를 작성하는데 해결이 되지 않는 문제가 있었다. 이름을 입력하지 않았을 때 오류 메시지가 잘 나오는지 테스트를 하는데 이름을 빈칸으로 하고 테스트를 해도 테스트가 통과가 되지 않는 상황이였다. 문제 상황 회원가입 시 이름을 입력하는데 빈칸이면 안되고 3~7글자 사이의 한글만 입력해야 하기 때문에 스프링의 @Valid어노테이션을 이용해 아래 같이 Dto클래스에서 유효성 검사를 진행했다. 그리고 이름이 빈칸일 때 테스트를 진행하는데 이름이 빈칸이면 "이름을 입력해주세요"라는 메시지가 나오게 했지만 밑에 오류 메시지를 보면 "이름을 다시 확인해주세요"라는 다른 조건(3~7글자 사이의 한글만 입력)이 틀렸을 때의 메시지가 나왔다. 그래서 @NotBlank와 ..

원문보기 내부링크
Tistory

221005 TIL 방법의 차이

어제 구현했던 페이지네이션 기능을 뭔가 정석대로 구현하지 않은 것 같아서 아침부터 계속 눈에 밟히고, 이게 맞나 싶은 찝찝함을 갖고 있었다. 기능을 구현할때 그 기능을 구현하기 위한 코드의 방법은 여러 가지가 있겠지만 나는 정답이 있을 거라고 생각을 하고 있었다. 그래서 페이지 네이션이라는 기능을 구현해도 정답에 가까운 코드가 아니라고 생각을 했기 때문에 찝찜함이 남아있었다. 내 코드가 정답이 아니라고 생각한 이유는 지금까지 코드를 배울때 아샬 님의 강의를 보면서 배웠는데 내가 페이지네이션을 구현하기 위해 쓴 코드가 이때까지 아샬님이 작성했던 코드와 거리가 있었기 때문에 구현해도 구현한 것 같지 않은 느낌이 있었다. 근데 오늘 노아트레이너님의 말씀을 듣고 그 찝찝함을 좀 덜 수 있었다. 내가 원하는 기능..

원문보기 내부링크
Tistory

221006 TIL 돌다리도 두들겨 보고 건너라

오늘 메인으로 구현했던 기능은 상품 주문 내역을 불러오는 기능인데 이전에 상품 내역을 불러오는 코드를 작성해놨기 때문에 비슷한 맥락으로 생각보다 금방 구현할 수 있었다. 순조롭게 상품 주문 내역에서 특정 주문 내역을 클릭 시 세부 정보를 얻어오는 기능도 구현하는데 주문내역의 id값만 받아오지 못하는 상황이 발생했다. 주문 내역의 아이디로 세부 정보에 접근하기 때문에 아이디 값을 받아오는 게 필요했는데 받아오지 못하니 세부 정보를 볼 수 없었다. 백엔드에서 dto로 id값을 전달하게 했는데 받아오는 값을 출력해서 확인해보면 id 빼고 모두 가져오는 것을 확인했다. 너무나도 아이러니하게 무조건 필요한 id값만 빼놓고 가져오니까.. 그래서 id를 생성을 하지 않는건가 생각을 했지만 주문 내역의 entity에 ..

원문보기 내부링크
Tistory

221007 TIL @ResponseBody, @RestController

어제 Dto클래스의 getter 메서드의 이름에 get을 뺐을때 발생했던 문제의 원인을 파악하기 위해 오늘 공부하고 정리한 내용이다. 우선 문제상황은 getter 메서드의 이름에 get을 뺐을때 그에 해당하는 값을 responseBody에 전달되지 않는 상황이다. 밑에 사진에서 원래는 id값도 전달이 되야하는데 Dto클래스의 getter인 getId 메서드의 이름을 get을 빼고 그냥 id로 바꾸고 실행한 결과값이다. @ResponseBody 그러면 responseBody에 대해서 먼저 알아봐야 할 필요가 있었다. 서버에서 클라이언트로 응답을 보낼 때는 데이터를 responseBody에 담아서 보내야 한다. 클라이언트에게 응답을 보내는 컨트롤러에서 @ResponseBody라는 어노테이션을 사용하면 자바의..

원문보기 내부링크
Tistory

221008 TIL 호이스팅(hoisting)이란?

금요일에 2기분들 코딩 인터뷰 때 호이스팅이라는 개념에 대한 질문이 나왔다. 사실 호이스팅이라는 단어를 난생처음 들었는데 호이스팅이 면접의 단골 질문이라고 하셨다. 호이스팅이 뭔데 단골 질문일까?? 한번 알아보자 호이스팅(hoisting) 호이스팅을 간단하게 말하면 함수가 실행되기 전에 안에 있는 변수들을 범위의 최상단으로 올리는 것을 말한다. 자 백날 말하는 것보다 코드 한번 쳐보는 게 이해가 훨씬 빠르니 코드를 한번 보자 var number = 1; console.log(number); 자 위 코드에서 콘솔에 찍히는 값은 뭘까? 당연히 1이다. console.log(number); var number = 1; 그러면 위 코드에서 콘솔에 찍히는 값은 뭘까? undefined가 콘솔에 나오는 것을 확인할..

원문보기 내부링크
Tistory

221002 TIL 거꾸로 로꾸거

오늘은 저번 주에 하지 못한 TDD 스터디를 하고 왔다. 오늘 TDD시간은 저번주에 참여를 못한고 이번 주에 진행한 게 아쉬울 정도로 유익했던 시간이었다. TDD를 배운지는 오래된 것 같지만 제대로 사용하지 못하고 있다는 느낌을 항상 받았고, 그 느낌이 오늘 TDD시간에 책의 예제를 따라 몹 프로그래밍을 하면서 확신으로 바뀌었다. TDD를 처음 배울 때 작은 단위부터 내가 컨트롤할 수 있는 범위 안에서만 수정을 시작하면서 빠른 그린을 봐야 하는 것을 배웠는데, 오늘 내가 했던 방법들을 돌이켜 보면 작은 단위로 TDD를 하기보다는 리팩터링 할 때 중간 과정을 많이 뛰어넘고 하고 있었다. 그래서 리팩터링 하다 길을 잃어버리는 경우도 종종 있었다. 근데 오늘 몹 프로그래밍을 하면서 진짜 엄청 작은 단위부터 시..

원문보기 내부링크
Tistory

221003 TIL 문서는 네비게이션

주말에 서버 배포하는 것과 문서를 작성하는데 시간을 사용해서 거의 진행을 하지 못했지만 오늘은 제대로 레벨테스트를 시작하는 하루였다. 저번 주부터 했어야 했던 프로그램을 만들면서 문서를 작성하는 연습을 저번 주에는 제대로 하지 않았었지만, 오늘은 내가 만들려는 것을 만들기 전에 문서에 api 스펙을 먼저 작성하면서 방향을 잡으니까 코드를 작성할 때 방향을 잃지 않는 느낌을 강하게 받았다. 문서가 하나의 네비게이션 역할을 해주고 있었다. 가끔 코드를 작성하다보면 다음에 뭘 해야 하지?라는 생각을 가끔 할 때가 있었는데, 오늘은 그런 일이 전혀 없었다. 왜냐하면 문서에 이미 뭘 해야 할지 작성을 다 해놔서 그거에 따라 하나씩 만들면 됐기 때문이다. 오늘의 목표는 상품 목록을 조회하는 기능을 구현하는것이 나의..

원문보기 내부링크
Tistory

221004 TIL Failed to create query....

Failed to create query for method public abstract 오늘 만난 오류는 Failed to create query for method public abstract이라는 오류를 만났다. JPA Repository에서 특정 id값의 데이터를 가져오다가 만난 걸로 추정이 되는데 당시에 마주했을 때는 왜 이런 오류가 발생했는지 파악할 수 없었다. 에러 메시지도 전부 빨간 글씨여서 잠깐 당황을 했다... 이렇게 에러 메시지를 띄워주면 당황스럽다고요.. 파란색으로 어떤 코드가 잘못되었는지 알려주는 에러들은 그나마 추적해나가면서 해결할 수 있는데 위 에러는 불친절하게도 그런 게 없다.. 근데 자바도 내가 잘못했으니까 저러겠지.. 심호흡 한번 하고 에러의 원인을 알려주는 Reason부..

원문보기 내부링크
Tistory

220929 TIL 쿠키(Cookie)와 세션(Session)

오후에 과제를 진행하던 중 홀맨님이 지금 시점에서는 세션과 쿠키의 차이를 "명확히" 알고 있어야 한다는 메시지를 보고 나는 쿠키와 세션을 명확히 알고 있는지 잠시 생각을 해봤는데 아무래도 아닌 것 같다고 판단이 되어 쿠키와 세션에 대해 알아보려 했다. 그런데 내일 안에 과제를 마무리하는 게 목표라 과제를 하는 것을 잠시 멈추고 쿠키와 세션을 바로 공부하는 게 맞는 건지 과제를 다 하고 알아보는 게 맞는 건지 잠시 고민을 했지만, 며칠 전 노아님이 이제는 과제 제출에 중점이 되어서는 안 되고, 과제 제출하는 것은 기본이고 실력을 쌓는 게 중점이 되어야 한다는 말씀을 해주신 게 생각이 나서 하고 있던 과제를 잠시 멈추고 바로 쿠키와 세션을 찾아봤다. cookie 쿠키란 서버가 사용자의 웹 브라우저에 전송하는..

원문보기 내부링크
Tistory

메가테라 14주차 회고

14주 차 회고 메가 테라 14주 차를 진행하면서 있었던 일을 종합해서 회고하였습니다. 마카오 뱅크(최종_최종_진짜최종..) 이번 주는 마카오뱅크를 만난 첫 주부터 바래왔던 마카오뱅크의 최종본을 맛보는 한 주였다. 이번 주는 강의를 보고 학습을 하는 마지막 주였다. 그래서 이번 주의 과제가 이때까지 배운 모든 것을 활용하여 회원가입, 로그인, 잔액조회, 송금, 거래 내역 확인 등등 여러 가지 기능을 하는 마카오뱅크 웹 서비스를 만드는 과제가 주어졌다. 마카오뱅크의 최종 모습을 보고 처음 들었던 생각은 금요일 안에 다 완성할 수 있을까..? 였다. 그만큼 만들어야 하는 사이즈가 컸었는데 사실 어느 정도는 강의만 제대로 보고해도 커버가 가능한 수준이었고, 회원가입과 로그인 부분만 조금 신경 쓰면 만들 수 있..

원문보기 내부링크
Tistory

220930 TIL 이름 짓기

오늘 점심에 TDD책 읽어야 하는 분량도 다 읽었는데 시간이 좀 남아서 실용주의 프로그래머 책을 꺼냈는데 어떤 주제를 읽을까 고민하다 눈에 띄는 한 주제가 있었고 바로 읽기 시작했다. 주제는 "이름 짓기"인데 프로그래밍을 시작하면서부터 지금까지 네이밍은 여전히 어려운 부분이기 때문에 눈에 바로 띄었던 것 같다. 프로그래밍을 맨 처음 혼자서 유튜브를 보면서 배울때는 변수 이름 짓는 거는 제일 쉬웠다. 왜냐하면 그냥 내가 하고 싶은 변수명으로 적거나, 주변에서 많이 사용하는 축약어 같은 거를 남발했었고, 누군가 내 코드를 보며 리뷰를 해준적도 없었기에 변수의 이름을 짓는 게 중요한지 알려주는 사람도 없었기 때문에 변수명에 대한 고민은 한 적이 없었다. 하지만 네이밍이 중요하다는것을 인지하고 난 뒤부터는 프로..

원문보기 내부링크
Tistory

221001 TIL 기억보단 기록을

오늘은 기억을 하는 것보다는 기록을 해야 한다는 것을 뼈저리게 느낀 하루였다. 어제 리액트로 만든 마카오 뱅크를 배포하는 과정에서 고통을 받고 있다가 진님이 젭에 접속하셔서 도움을 요청했다. 진님과 오랜 시간 동안 많은 실험을 해보면서 리액트 앱 배포 문제를 해결을 할 수 있었다. 그래서 그 배포한 해결방안을 오늘 오후에 동료들에게 알려주는데 어떻게 했는지 중간 과정들이 하나씩 기억이 제대로 나지 않아 큰 도움을 주지 못했다. 어젯밤에 했던 것들이라 생각이 날줄 알았지만 막상 내가 남에게 알려주려고 하니 생각이 하나도 나지 않았다... 그래서 아 어제 기록 좀 해놓을걸이라는 후회를 함과 동시에 얼마 전에 들어갔던 이동욱 님의 블로그 제목이 기억이 났다. 기억보단 기록을 오늘부터 문제를 마주치면 깃허브 레..

원문보기 내부링크
Tistory

220926 TIL 책은 미리미리 읽자

드디어 드러난 마카오 뱅크의 실체 오늘은 드디어 마카오 뱅크의 최종 모습을 볼 수 있었다. 그리고 이때까지 배운 것을 총동원하여 마카오 뱅크 웹페이지를 만드는 게 최종 과제이다. 약 4달 전 마카오 뱅크를 처음 본 뒤 마카오 뱅크는 끝까지 함께한다던 트레이너님의 말을 듣고 충격을 받았었는데 드디어!! 마카오 뱅크의 실체를 볼 수 있었다. 몰아서 보지 말고 미리 읽자 주어진 마카오 뱅크 과제를 다 만들려면 이번 주 아주 빠듯하게 작업을 해야 한다고 판단되었다. 하지만 그 와중에 스스로 약속한 게 있다. 바로 TDD책을 하루에 한 챕터씩 읽는 것이다. 원래 저번 주 주말에 TDD 스터디에 참가해야 했는데 참석하지 못했다. 이유는 토요일 저녁이 되어도 주말 강의를 1번도 다 보지 못했고 TDD책 읽어야 하는 ..

원문보기 내부링크
Tistory

220927 TIL 놀랍다..! Pageable

오늘은 마카오 뱅크의 거래내역 조회 기능을 구현하다 pagination을 아주 간단하게 구현하는 유용한 기술을 발견했다. pagination은 게시판 같은 데서 흔하게 볼 수 있는 개념이다. 게시글의 수가 특정 개수를 넘어가면 다음 페이지를 클릭해서 이동이 가능하게 해주게 하는 것을 pagination이라고 하는데 이전 과제에서 이 pagination을 구현해야 했던 적이 있다. 어려서부터 컴퓨터를 사용할 때 특정 게시글수가 넘어가면 다음 페이지가 존재하는 것은 너무나도 당연하게 여겨져 왔던 사실이라 이것도 프로그래밍해서 만들어졌다는 것을 인지하지 못하고 있었는데 과제로 주어지고 막상 만들려고 하니까 너무 어렵게 느껴졌었고 구현하기 위해 조건식 막 만들고 엄청 고생했던 기억이 난다. 근데 그 고생을 왜 ..

원문보기 내부링크
Tistory

220928 TIL 풀스택 개발자로 가는 길

백엔드와 프론트엔드의 경계 매번 프론트엔드와 백엔드를 독립적으로 배워서 이 둘의 경계가 어디인지 왜 나눠서 사용하는지 정말 애매했었다. 리액트만으로도 투두리스트나 마카오 뱅크가 만들어지고 스프링만으로도 만들어지는데 왜 나눠서 사용할까...? 이런 궁금증은 항상 갖고 있었다. 이번 주에 둘을 같이 사용하여 마카오 뱅크를 만들어 보면서 그 경계를 조금이나마 허물 수 있었다. 그리고 이번 주 강의만 봤을 때는 이 둘을 어떻게 연결시키는 건지 잘 이해가 되지 않았었는데 오늘 직접 해봄으로써 조금이나마 이해할 수 있었다. 입력 폼에 대한 예외처리를 하는 것을 직접 해봤는데 처음에는 어떻게 해야 할지 전혀 감이 잡히지 않아 헤매고 있었다. 백엔드에서 입력하는 폼에 대한 조건을 따져서 조건에 맞지 않으면 예외 메시지..

원문보기 내부링크
Tistory

메가테라 13주차 회고

13주 차 회고 메가 테라 13주 차를 진행하면서 있었던 일을 종합해서 회고하였습니다. 내가 아는 리액트는 리액트가 아니었다.. 이번 주는 저번 주의 연장선인 리액트를 이어서 배웠다. 저번 주에 리액트를 배우고 마카오 페이라는 퀘스트를 만들면서 재미있었기 때문에 이번 주도 재밌는 한 주가 되겠구나 생각을 했다. 하지만 3번째 강의를 접한순간부터 내가 저번 주에 배웠던 리액트는 장난이었다는 것을 깨닫게 되었다... api에서 받아온 데이터를 테스트할 때 mock을 이용해 테스트하는 여러 가지 방법, Flux Architecture의 store개념, Pub-Sub 패턴의 구독하는 이유와 구독을 끊는 이유 등등 이해하기 어려웠던 개념들이 넘쳐났고, 그 개념을 바로 적용해서 간단한 게시판을 만드는데 그 과정이 ..

원문보기 내부링크
Tistory

220923 TIL 자신감을 갖자

코딩 인터뷰 시간에 받은 지적 중 하나가 말할 때 너무 자신감이 없다는 것이다. 질문에 대해 답을 할 때 내가 맞는 답을 말하는지 확신을 갖지 못하니까 쭈굴이 모드로 변해서 자신감 없는 모습이 나왔던 것 같다. 내가 말하는 게 맞든 틀리든 자신감 있게 대답을 하는게 중요하다고 말씀을 해주셨다. 피드백을 받은 이후에 다음 질문은 맞든 틀리든 최대한 자신감 있게 내가 생각하는걸 말을 하니까 조금 괜찮아졌다는 말씀을 해주셨고 스스로도 쭈굴이 모드로 말하던 때랑 달라졌다는 걸 체감할 수 있었다. 내 차례가 끝나고 이전부터 글을 잘 쓰신다고 생각했던 동료분이 인터뷰하시는 걸 보는데 확실히 나와 다르다는 것을 느꼈다. 동료분이 인터뷰하는 걸 보면 나와 달리 질문에 대한 답과 상관없이 말을 하실때 목소리에 힘이 들어..

원문보기 내부링크
Tistory

220924 TIL 당황하지마 언제나 쉬운건 없었어

오늘 아침에는 평소 주말에 일어나는 시간보다 눈이 일찍 떠져서 일어난 김에 어떤 강의가 올라왔는지 확인만 하고 조금만 더 자려고 했지만 강의 페이지를 보자마자 잠이 확 깨버렸다. 꿈을 꾸고 있는 건지... 눈이 안 좋아져서 강의가 여러 개로 보이는 건지 강의 리스트가 어마 무시했다. 총정리 주간이라 어느 정도 양이 있을 거라고는 생각했지만 이 정도일 줄을 상상도 못 했다.. 하지만 이제는 한 주가 지날수록 배우는 양이나 난이도가 급상승하는 건 익숙해져 있던 터라 당황하지 않고 (사실 오늘은 많이 당황하긴 했는데..) 자리에서 일어나 강의를 볼 준비를 했다. 평소에는 주말에 강의를 시간 분배를 하면서 계획적으로 보는 편이었는데 오늘은 그럴 여유도 없이 강의를 바로 보기 시작했다. 총 정리 주간이라서 완전히..

원문보기 내부링크
Tistory

220925 TIL 구멍이 송송

오늘 하루 강의를 보면서 가장 많이 느꼈던 것은 내가 놓치고 넘어간 것들이 많다는 것이었다. 놓친 개념들이 많다 보니 복습하는 주간임에도 불구하고 새로 학습하는 기분이 들었다. 오늘 중점적으로 공부를 했던 부분은 mock을 이용한 테스트와 axios테스트 부분이다. 이전에 axios를 테스트하는 부분을 처음 배웠을 때 너무 어려워서 이해하지 못하고 강의에서 나온 형태 자체를 외우고 사용을 했었기 때문에 오늘 그 부분을 다루는 강의를 중점으로 봤다. 그리고 스프링에서 mock객체를 이용해서 테스트하는 부분도 이때까지 제대로 이해하지 않고 사용하고 있다는 것을 다시 한번 개념 정리하면서 깨달았다. 가짜 API 서버를 만들어서 테스트하는게 아직도 익숙하지 않아서 할 때마다 애를 먹고 있었는데 이번에 MSW라는..

원문보기 내부링크
Tistory

220919 TIL 쉬운게 없는 하루

요즘 들어 뭐 하나 쉬운 게 없어서 하루의 목표를 세우면 그 목표를 제대로 완료하는 게 없는 상황이다. 오늘 올라온 코딩 도장 문제도 혼자 풀고 싶었지만 시간이 오래 지나도 못 풀었다. 지금 강의 인출도 제대로 되지 않고, 퀘스트도 시작도 못한 마당에 이걸 붙잡고 있는 게 맞는 건가? 생각이 들어서 풀이 방법을 찾아서 제출을 하긴 했다. 강의 인출도 오늘 제대로 하지 못했다. 6시 안에 제출해야 한다는 마감시간이 있었지만 그 시간을 지키지도 못해서 강의 반복 과제도 일단 강의를 보면서 따라친것을 제출했다. 우선 항상 트레이너님이 강조하시는 마감시간을 지키기 위해 어떻게든 제출은 하고 있지만 이렇게 하고 있는 게 맞는 건지 혼란스럽고 답답했다. 능동적으로 뭔가 해내는 게 없다는 사실이 의욕을 자꾸만 꺾이게..

원문보기 내부링크
Tistory

220920 TIL JUST DO IT!

일단 하자 어제 퀘스트를 거의 진행하지 못했었다. 어디서부터 어떻게 진행해야 할지 몰랐고, 어떻게 저 기능을 구현해야 하지?라는 막막함이 아무것도 진행할 수 없게 만들었다. 그래서 어제는 강의를 한 번 더 듣는 시간을 가졌지만 오늘은 나름 퀘스트 진행이 되고 있다. 어제 강의를 한 번 더 들었다고 오늘 퀘스트를 어떻게 할지 감이 잡힌 건 아니었다. 하지만 어제와 오늘의 나의 차이는 오늘도 아무것도 못한 채 생각만 한다면 큰일 날것 같아서 일단 시작하는 거였다. 어제처럼 전체적인 완성된 그림을 생각하고 어떻게 그려나가야 할지 방법을 먼저 생각하고 시작하는 게 아니라 진짜 작은 부분, 내가 만들 수 있는 부분부터 차근차근 하나씩 만들어 갔다. 차근차근 하나씩 만들다 보니 "아! 이것도 필요하겠다. 그러면 저..

원문보기 내부링크
Tistory

220921 TIL 목표는 완성하기

뽀그로 타이머 과제 리뷰 중 useState로 상태 값을 관리하던 것을 store에서 관리해야 한다는 리뷰를 받았다. 즉 Flux Architecture를 직접 적용해야 할 때가 왔다는 뜻이다. 이번 주 강의를 들으면서 가장 이해가 안 되고 어려웠던 Flux Architecture.... 그리고 추가로 구독이라는 개념이 나오면서 Pub-Sub패턴도 배웠는데 이것 또한 이해하기가 쉽지 않았다. 일단 내가 지금까지 내가 이해한 Flux Architecture에 대해 먼저 정리해보자. Flux Architecture 우선 Flux Architecture는 MVC패턴의 한계를 해결하기 위해 등장한 아키텍처라고 한다. MVC패턴은 데이터 흐름이 양방향이기 때문에 애플리케이션의 복잡도가 높아 확장하기가 어렵다. 반..

원문보기 내부링크
1 2 3