# F12

jswtncapetnc

간단하게 개발자 도구 살펴보기 콘솔편 이번 포스팅에서 개발자 도구의 정의와 개발자 도구의 사용법을 알아봅시다.

ohzzi

지난 시간에 인덱스를 활용하여 어떻게 하면 쿼리 성능을 개선할 수 있을지 MySQL 콘솔을 통해 실험해가며 알아보았습니다. 그를 통해 개선된 쿼리를 만들어 낼 수 있었죠. 하지만 저희 팀 서비스는 결국 스프링과 JPA를 사용한 웹 애플리케이션이고, 개선된 쿼리를 자바

ohzzi

레벨 4는 프로젝트가 주가 아니라는 생각에 레벨 4 초반에는 프로젝트보다는 개인 공부에 집중했었다. 백엔드 쪽 요구사항으로 인덱스와 스레드 설정이 주어졌었는데, 오히려 잘 모르다 보니 오래 고민하고 오래 테스트 해봐야 한다는 것을 몰라서 쉽게 끝낼 수 있을 거라고 착각

ohzzi

우아한테크코스에서는 팀 프로젝트를 진행중입니다. 그 중 이번 5차 데모 데이의 백엔드 요구 사항으로 다음과 같은 부분이 있었습니다.서비스에서 사용하는 쿼리를 정리하고, 각 쿼리에서 사용하는 인덱스 설정서비스에서 사용하는 모든 조회 쿼리와 테이블에 설정한 인덱스 공유인덱

ohzzi

이번 주 개발일지를 쓰지 않았다. 레벨 3 막판이 되어 나태해진 것인지… (물론 그렇다고 작성해야 할 코드를 작성하지 않거나 해야 할 공부를 안하지는 않았다.) 그래도 레벨 3를 마무리하는 입장에서 이번 주 어떤 일들을 했고 어떤 이슈가 있었는지에 대해 남길 필요가 있

ohzzi

기존에는 예외가 터질 때 마다 예외 상황을 나타내는 메시지를 담은 response를 보내주었었다. 하지만 이렇게 하니까, 프론트엔드에서는 백엔드가 보내주는 메시지에 의존해서 개발을 할 수 밖에 없다는 문제가 있었다. (상태코드 + 에러 메시지 형태인데 상태 코드는 세분

ohzzi

어제 하지 못했던 7인 몹 프로그래밍을 진행했다. 몹으로 진행하기로 한 핵심 기능은 제품 검색 기능이었는데, 백엔드 쪽에서는 인수 테스트 시나리오를 작성한 뒤 레포지토리 단부터 TDD로 올라오는 방식의 프로그래밍을 진행했다. if문으로 카테고리를 분기하고 있던 부분을

ohzzi

원래는 오늘 매 스프린트마다 요구사항 중 하나인 스프린트마다 FE에서 BE를 관통하는 기능 중 최소 하나를 FE/BE 페어로 개발을 만족하기 위해서 제품 검색 기능에 대해 팀원 7명이 모두 참여하는 7명의 페어몹 프로그래밍이 있을 예정이었다. 하지만 어제 중부지방에 내

ohzzi

이전까지는 백엔드 WAS가 띄워져 있는 EC2에 로컬로 h2 데이터베이스를 띄워놓고 사용중이었다. 인바운드 규칙에 보통 DB 포트로 사용하는 3306 포트가 제대로 열려있지 않기도 했었고, 데이터베이스 스키마가 계속 바뀌고 있는 상황이어서 MySQL을 올리고 나면 계속

ohzzi

front-main, back-main, front-test, back-test 총 네 개의 EC2 인스턴스에 모두 HTTPS 적용을 완료했다. 가비아를 통해 구매한 도메인은 f12.app으로, 서브도메인을 활용하여 www.f12.app은 메인 프론트엔드에, prod.

ohzzi

어제부터 우리 팀을 괴롭혔던 REST Docs가 보이지 않는 이슈를 해결했다. 표면적인 이유는 Jenkins 빌드 시 workspace를 삭제하도록 변경한 이후로 REST Docs가 보이지 않는 것이 맞았다. 하지만 실제 원인은 다른 곳에 있었는데, 애초에 REST D

ohzzi

오늘 진행한 일 코드 리뷰 개발팀(코린/티키, 클레이)이 작성한 코드에 대한 코드 리뷰를 진행했다. 개발팀을 둘로 나눠서 진행하고 워낙 많은 수정 사항이 있어서 코드 리뷰를 할 양이 많았다. 핵심적인 변경사항이 있었는데, 우선 사용자 검색 기능과 카테고리를 기반으로

ohzzi

블링과 함께 프론트엔드 메인 서버의 nginx가 정적 파일을 뱉어내지 않는 오류를 해결했다. nginx 설정을 초기화 해보기도 하고, nginx를 아예 지우고 다시 설치해보기도 했는데, 정말 황당한 오류였다. nginx에 권한을 제대로 주지 않은 오류였다. 권한을 적절

ohzzi

정신없고 피곤한 이틀이 지나가다 보니 개발일지가 밀렸다… 사실 별로 한 내용도 크게 없어서 쓸 내용도 없기는 하지만 우선은 이틀 동안 한 내용이라도 정리해야 할 것 같다.F12의 백엔드는 외부로 유출되어서는 안되는 여러 정보들을 사용한다. 첫째는 바로 GitHub OA

ohzzi

스프린트 2 데모데이를 위한 배포 버전이 수요일을 끝으로 완료되어서, 수요일까지 미처 마무리하지 못한 자잘한 기능들을 구현은 하되 배포는 데모데이가 끝난 이후 진행하기로 했다.테스트 코드 실행 속도가 느린 점을 해결하기 위해 리팩토링동일 장비에 대해 한 회원이 여러 리

ohzzi

우리 서비스의 비즈니스 규칙으로 리뷰를 작성하면 그 리뷰의 대상인 장비가 작성자의 인벤토리에 자동으로 추가된다.를 정했다. 여기서 나와 블링의 의견이 갈렸는데, 나는 서비스 규칙으로는 리뷰를 작성하면 장비가 인벤토리에 추가되어야 하지만, API 설계적인 측면에서는 요청

ohzzi

현재까지 구현한 리뷰 기능은 C,R 기능만 있고 U,D 기능이 존재하지 않았기 때문에 리뷰의 수정, 삭제 기능을 추가했다. 수정과 삭제 모두 로그인한 회원 정보와 수정/삭제 하려는 리뷰를 findById로 찾아오고, Member에 정의해 놓은 isWrittenBy 메서

ohzzi

인증 인가 기능이 완료되었으므로 이제 인증 인가 기능을 활용할 차례다. 인증 인가 기능의 마지막에 리뷰 작성의 경우 반드시 유효한 토큰이 있어야만 작성할 수 있도록 설정했는데, 여기서 가져온 회원 정보로 리뷰와 연관관계를 맺어주는 작업을 진행했다.이 때 우리끼리 정한

ohzzi

인증 로직이 완성되었으니 인가 로직을 구현하는데 집중했다. 인가 로직은 이미 레벨 2 장바구니 미션에서 인터셉터와 리졸버를 통해 구현하는 것을 배웠기 때문에 해당 부분을 코드에 적용하느라 어렵지 않았다. 하지만 인터셉터를 특정 URL이 아닌 특정 메서드에 적용시키는 방

ohzzi

F12 서비스는 개발자의 프로필을 중심으로 하기 때문에 개발자들이 가장 많이 사용하는 플랫폼인 GitHub의 프로필을 사용하려고 한다. 그래서 인증 방식으로 GitHub OAuth + JWT 방식을 사용하기로 했다. GitHub OAuth 인증 방식의 플로우는 다음과