sosow0212의 등록된 링크

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

Naver Blog

[24.08] 사이판 여행

24.08.07 - 24.08.12 여자친구와 여름에 사이판에 다녀왔습니다. 먼저 저희 둘다 괌은 다녀왔는데, 괌이 너무 예뻤어서 이번에는 괌 바로 옆인 사이판에 가기로 했습니다. 사이판은 투어 외에는 섬 자체가 너무 작고 할게 없어서 심심했고, 숙소와 물가가 생각보다 많이 비쌌습니다. 켄싱턴, 크라운 숙소 모두 1박에 20만원 정도 하는데 그정도로 좋진 않기 때문에 차라리 괌이 더 좋은 것 같습니다. 그래도 너무 예쁘고 바다만 봐도 좋아서, 조용한 휴양지를 가고 싶다면 사이판도 괜찮습니다! 아이러브사이판 이거랑 아이러브괌 사장님이 한국 사람인거 아셨나요? 저도 투어 가이드한테 들었습니다 ㅋㅋㅋㅋ 저기 가자마자 아이러브사이판 티셔츠를 샀는데, 지금도 잠옷으로 잘 입고 있습니다~ 사이판은 되게 작은 섬인데요. 아이러브사이판 나와서 앞에 있는 버거집에서 윙이랑 버거를 사서 먹었는데 역시 맛있었습니다. 숙소 앞에 바다로 바로 갔습니다! 역시 바다 정말 깨끗하고 보기만 해도 힐링이 되는 장

Naver Blog

[24.11] 밍구와 함께하는 당일 예약 무계획 후쿠오카 여행기

공채 최종합격 소식을 목요일 저녁 늦게 메일로 확인하고 기쁜 마음으로 여자친구한테 전화 했습니다. 입사가 당장 11월 25일이기 때문에 원래 계획한 발리 한 달 살이는 못하게 되었고, 아쉬운 마음에 같이 여행을 가기로 했습니다! 새벽까지 알아봤지만 일본, 동남아 등등 모든 항공권이 5~60만원이나 하고 숙박은 더 비싸서 아쉬운 마음에 그냥 잤습니다 ㅠㅠ 아침 일찍 여자친구가 전화해서 후쿠오카 항공기랑 숙박을 찾았다고 하길래 당장 부랴부랴 씻고 정신 없이 인천으로 차타고 달려갔습니다. 15시 비행기가 있어서 바로 10시에 양말도 챙기지 못한 상태로 떠났습니다 ㅋㅋ 이렇게 저희의 취업 파티 무계획 후쿠오카 여행이 시작 됐습니다. 여자친구 집이 검단신도시라 주차를 해놓고, 근처 계양역 공항철도를 타니 30분만에 도착했습니다! 민주가 밥을 잘 안 먹는데 한식이 땡긴다해서 공항에 소문난집? 이라는 한식집에서 맛나게 먹고 비행기를 바로 탔습니다. 역시 공항은 언제 가도 너무 설렙니다~~ 비행기

Naver Blog

코틀린과 헥사고날 아키텍처에 대해

안녕하세요. 굉장히 오랜만에 학습 포스팅 글을 작성하는 것 같습니다. 벌써 입사 한 달이 다 됐는데 시간이 참 빠른 것 같습니다! 취업을 해도 공부를 하는 것은 변함이 없지만 그래도 이제는 궁금했던 것들을 학습할 수 있게 돼서 좋은 것 같습니다. 입사 후 2주는 펑펑 놀았고, 이제는 퇴근하고 조금씩 공부를 하고 있는데 현업에서 사용하는 개념적인 것들과 궁금했던 아키텍처에 대해서 학습을 먼저 진행 했습니다. 재밌게 학습을 하고 싶어서 가장 대중적인 주제인 [상품 주문, 결제, 배송] 시스템을 간단하게 만들면서 학습을 진행하고 있습니다. 오늘 진행한 코드에 대해서는 아래 레포지토리에서 확인하실 수 있습니다. https://github.com/sosow0212/order-process/pull/1 코틀린과 헥사고날 아키텍처에 익숙하지 않아서 틀린 부분이 있을 수 있는데, 틀린 부분이 있다면 피드백 부탁드립니다. 목차 코틀린에 대해 레이어드 아키텍처와 헥사고날 아키텍처에 대해서 (+ Dom

Naver Blog

[25.01] 다시 돌아온 상하이 여행

https://blog.naver.com/sosow0212/223653421271 [24.01] 우끽끼 민주와 신나는 상하이 여행 2024.01.29 - 24.02.06 올해 2월에 여자친구와 상하이에 다녀왔습니다. 처음에 중국에 대해 무섭기도 하고 ... blog.naver.com 설날 황금 연휴 기간에 여자친구랑 상하이를 다녀왔습니다. 작년 1월에 갔다가 1년만에 다시 갔네요! 동방항공을 탔는데 기내식이 나왔습니다. 중국식 돼지고기 덮밥인데 별로였고 저기 빵과 과자는 맛있었습니다~ 숙소는 상하이 푸동에 있는 '더 이튼 호텔'입니다. 작년에도 여길 갔고 올해 더 좋은 곳 갈까 하다가 다 비슷비슷하고 위치도 좋고 깨끗하고 무엇보다 배달도 1층으로 시키면 가져갈 수 있어서 한 번 더 왔습니다. 여자친구도 저도 너무 만족하는 숙소라서 앞으로 상하이에 또 간다면 또 여기로 올 것 같아요. 인민광장이나 난징동루나 다 가깝기 때문에 깨끗한 이튼 호텔이 더 좋은 것 같습니다. 사실 저희가 상하

Naver Blog

[개발 일기 #31] 3개월 간 신입 개발자는 무엇을 했을까?

24년도 11월 25일에 입사하고 벌써 3개월이 지났다. 그리고 오늘 수습 기간이 끝나고 정직원이 됐다. 3개월, 약 90일 동안 신입 개발자로서 나는 어떤 것을 배웠고 무엇을 했을까? 또한 개발 외에 어떤 것에 관심이 생겼을까? 3개월 간 수습 생활을 돌아보고자 회고록을 남겨본다. 입사, 나의 팀 24년도 11월 25일 월요일 첫 출근을 했다. 입사 동기는 총 8명. 나와 같은 개발자 직무인 동기는 나 포함 총 4명이고, 엔지니어 직무인 나머지 4명은 아쉽지만 OT 기간이 끝나면 서초/가산으로 발령이 난다고 알고 있었다. 근무 지역이 달라지지만 그래도 서로 대화도 많이 하고 저녁도 먹고 일주일 OT 기간을 함께 재밌게 보냈다. 다들 너무 성격이 좋아서 마음이 편했다. 인사팀과 다양한 부서에서 신경을 써주신 덕분에 OT기간에 회사가 무엇을 하는지, 어떻게 나아가는지 알 수 있었고, 비즈니스 매너 같은 기본적인 예절과 회사 문화와 생활에 대해 배울 수 있었다. (진짜 놀금 복지는 최고

Naver Blog

E-Market #10 - Infra 3편 : Jenkins 무중단 배포 설정 및 Docker를 이용하여 서버를 띄우도록 CD 방식 변경

Infra 시리즈 1편 : Jenkins를 이용한 CI/CD 파이프라인 구축하기 https://blog.naver.com/sosow0212/223369462311 2편: Spring Boot Actuator, Prometheus, Grafana로 모니터링 환경 구축하기 https://blog.naver.com/sosow0212/223369973401 3편: Jenkins 무중단 배포 설정 및 Docker를 이용하여 서버를 띄우도록 CD 방식 변경 https://blog.naver.com/sosow0212/223371181808 안녕하세요. 지난 포스팅에 이어서 오늘은 무중단 배포과 함께 기존 jar를 전달 받아 실행한 방법에서 docker image를 실행하는 방법으로 변경을 했습니다. 앞서 설명 드렸지만 저희 서비스는 EC2 인스턴스가 현재 infra, Dev, DB 이렇게 세 개로 나눴는데요. 그 이유는 인스턴스 분리를 통해 관심사에 맞는 각자의 역할을 수행할 수 있도록 관리와

Naver Blog

E-Market #11 - 멀티모듈 전환 1편 : 메일링 기능과 API 기능을 분리하기

[멀티모듈 전환 1편 - 멀티모듈로 전환한 이유] (https://blog.naver.com/sosow0212/223401237314) [멀티모듈 전환 2편 - Redis Pub/Sub으로 외부 이벤트 수신, 스케일 아웃 환경에서 중복 스케줄링 막기] (https://blog.naver.com/sosow0212/223408645604) 안녕하세요. E-Market 프로젝트에서는 회원가입을 진행하면 가입자에게 메일로 쿠폰을 전달해주는 기능이 있습니다. 이전 포스팅에서는 메일 비동기 전송 처리 및 실패 메일 재전송을 다뤘습니다. (작업물 - https://blog.naver.com/sosow0212/223322476947) 즉 이전 과정까지는 다음 순서대로 메일링 기능이 진행되었습니다. 유저가 회원가입 한다. (Commit) 이벤트를 발행한다. 이벤트를 수신 및 메일을 비동기로 전송한다. (Commit) 만약 네트워크 지연 혹은 어떤 이유로 메일을 전송하지 못했다면 데이터베이스에 FAI

Naver Blog

E-Market #12 - 멀티모듈 전환 2편 : Redis pub/sub으로 외부 이벤트 수신, 스케일아웃 환경에서 중복 스케줄링 막기

[멀티모듈 전환 1편 - 멀티모듈로 전환한 이유] (https://blog.naver.com/sosow0212/223401237314) [멀티모듈 전환 2편 - Redis Pub/Sub으로 외부 이벤트 수신, 스케일 아웃 환경에서 중복 스케줄링 막기] (https://blog.naver.com/sosow0212/223408645604) 안녕하세요. 저번 포스팅에서는 기존 단일 서버를 api-server와 batch-server로 서버를 분리하였습니다. (++ 프로젝트 규모가 작기 때문에 batch-server는 batch 작업만 수행하지 않고 외부 라이브러리에 대한 기능도 수행합니다.) 관심사의 분리와 유동적인 스케일아웃을 위함이었는데요. 오늘은 서버를 분리하면서 이벤트를 수신하는 것과 batch 서버를 스케일아웃 했을 때 중복되는 스케줄링 문제는 어떻게 해결할 수 있었는지 작성해보도록 하겠습니다. 아래 사진은 최종적으로 개선한 아키텍처입니다. 지난 번에는 멀티 모듈로 전환하였고,

Naver Blog

중복 결제를 멱등성을 이용하여 막아보기 (토스페이먼츠 - 멱등성이 뭔가요?)

안녕하세요. 최근에 토스페이먼츠의 기술 아티클인 '멱등성이 뭔가요?'를 읽고 직접 구현과 생각을 정리해봤습니다. https://docs.tosspayments.com/blog/what-is-idempotency 멱등성이 뭔가요? | 토스페이먼츠 개발자센터 생소한 표현이지만 알고 보면 쉬워요. 멱등성에 대해 이해하고 API를 멱등하게 제공하기 위한 방법도 함께 알아봐요. docs.tosspayments.com 직접 진행한 예제 코드는 아래 깃허브에서 확인하실 수 있습니다. 부족한 부분이 있을 수도 있고, 필드도 최대한 간소화해서 진행했으니 참고만 해주세요 :) https://github.com/sosow0212/payment_with_idempotency GitHub - sosow0212/payment_with_idempotency Contribute to sosow0212/payment_with_idempotency development by creating an account on

Naver Blog

RestTemplate을 Transaction과 함께 쓸 때 주의해야할 점에 대해 (+ 캐싱과 함께 사용할 때 고민한 점과 해결방법)

안녕하세요. 최근에 RestTemplate에 대해 배운 점이 있어서 포스팅으로 작성하게 되었습니다. 저는 평상시에 크롤링을 할 때 RestTemplate을 사용하곤 했는데요. 타임아웃에 대해 인지하지 못하고 있었습니다. 상황에 따라 다를 순 있겠지만, 타임아웃 설정에 따라서 문제가 생길 수 있는 부분이 있습니다. 이 부분에 대해서 글로 다뤄보도록 하겠습니다. 목차 예시 설명 RestTemplate에 Timeout을 적용하지 않은 경우 시나리오와 문제점 RestTemplate에 Timeout 설정하기 RestTemplate을 캐싱과 함께 사용할 때 했던 고민과 해결방법 (캐싱에 더 가까운 고민) 1. 예시 설명 예제에서 사용되는 코드 이해를 위해 간단하게 예시부터 설명드리도록 하겠습니다. 먼저 스케일아웃 되지 않은 단일 서버이고, Java + Spring Framework로 작성된 코드입니다. 그리고 캐싱같은 경우는 단일 서버이므로 글로벌 캐시가 필요 없어서 자바에서 제공되는 Conc

Naver Blog

pop-cloud #1 : 멀티 모듈 및 프로젝트 기초 세팅 작업

안녕하세요. 상반기에는 mju-market 이라는 졸업작품 프로젝트를 만들었습니다. 학교와 관련된 주제를 하다보니 원하고 애정있는 프로젝트는 아니었지만, 많은 것을 배울 수 있었습니다. 이번 프로젝트는 아쉬웠던 부분을 해소하고 정말 해보고 싶은 개발을 하고 꾸준하게 유지보수하고 싶은 생각에 같이하는 친구와 정말 많은 고민을 했습니다. 좋아하는 주제로 좁히고 좁히다 팝업스토어 및 개인 전시회까지 다룰 수 있는 서비스로 정해졌습니다. 이미 팝업스토어 관련 서비스는 있지만, 차별점을 만들고 개선하는 것을 목표로 정했습니다. 기존에 사용자들은 SNS를 통해 흩어진 정보들을 찾는데, 이 부분을 개선하고 개인 전시회까지 이어나갈 수 있도록 애정을 가지고 개발하고자 합니다! 서비스 깃허브 https://github.com/sosow0212/2024-pop-cloud 포스팅과 관련된 PR https://github.com/sosow0212/2024-pop-cloud/pull/6 1. 멀티 모듈 분

Naver Blog

pop-cloud #2 : Redis를 이용한 인기 쇼케이스 캐싱 및 조회수 치팅 방지하기, Batch 스케줄러 작업 추가

안녕하세요. Pop-cloud의 가장 중요한 뼈대 작업을 어느정도 마치고 본격적인 트러블슈팅과 성능 개선 작업을 진행하고 있습니다. 아직 배포까지는 갈 길이 멀지만 천천히 트러블슈팅과 학습을 하며 진행하도록 하겠습니다. 저희 서버 Repository는 아래 링크를 통해 확인하실 수 있습니다. https://github.com/sosow0212/2024-pop-cloud/tree/develop/backend 오늘 작업한 PR 범위는 아래와 같습니다. https://github.com/sosow0212/2024-pop-cloud/pull/29 feat: Popups, Recommend의 캐싱 작업 및 배치 스케줄러 추가 by sosow0212 · Pull Request #29 · sosow0212/2024-pop-cloud Summary 1. PR 내용 요약 2. 기술 사용 근거 및 고민한 지점에 대해서 2-1. Redis 사용 이유 2-2. Redis 고민 지점 (캐시 스탬피드 및

Naver Blog

pop-cloud #3 : 중복 스케줄러를 막고, 실패시 재처리 작업 진행하기 (DistributionLock, Idempotency, Retry)

안녕하세요. 오늘은 팝 클라우드에서 사용되는 스케줄러 작업의 중복을 막고 실패시 재처리 하도록 만드는 과정에 대해서 작성하도록 하겠습니다. 팝 클라우드에서는 IP 캐싱 초기화와, 인기 팝업스토어 산정 초기화 작업에 대해서 매일 새벽에 작업을 시행하고 있습니다. batch 서버는 SPOF 지점이라 MVP 배포시 스케일아웃할 예정입니다. 만약 다중 환경에서 매일 새벽 2시에 돌아가는 스케줄이 있다면 중복 작업 처리가 될 여지가 있습니다. 먼저 이를 막는게 첫 단계입니다. 두 번째는 스케줄링 작업이 실패하면 어떻게 될까요? 매일 새벽 2시에 작업이 수행되지만, 사용자 입장에서는 만료된 팝업 스토어 정보가 보일 수 있습니다. 따라서 스케줄링 처리시 재처리를 할 수 있도록 별도의 장치를 설정해주었습니다. Spring-batch로 처리하지 않고 최대한 기본 작업에서 처리하고자 아직 Batch는 적용하지 않았다는 점 이해 부탁드립니다! 오늘 소스코드가 담긴 작업 PR 범위는 다음과 같습니다. h

Naver Blog

pop-cloud #4 : 지도에서 추천 경로 탐색을 위한 확장성 있는 코드 설계하기

안녕하세요. 오늘은 저희 팝 클라우드 서비스에서 지도로 추천 경로를 어떻게 다뤘는지 작성하고자 합니다. 범위가 많은 PR이지만 작업 내용은 아래에서 확인하실 수 있습니다! https://github.com/sosow0212/2024-pop-cloud/pull/84 feat: 좌표 기준 주변 쇼케이스 탐색 및 추천 경로 반환 기능 구현 by sosow0212 · Pull Request #84 · sosow0212/2024-pop-cloud Summary Map API 좌표 기준 주변 쇼케이스 탐색 기능 추가 추천 경로 반환 기능 추가 shortest path (다익스트라 기반 최단 경로 조회) popular path (조회수, 좋아요 수를 기반으로 인기순 조회) 🏻 More close #20 github.com 목차 기능 소개 설명에 앞서 간단한 코드 설명 DI를 활용한 확장성 있는 구조 설계 1. 기능 소개 팝 클라우드 서비스에서는 (1)사용자 현재 위치 기준 주변 쇼케이스 탐색

Naver Blog

[24.01] 우끽끼 민주와 신나는 상하이 여행

2024.01.29 - 24.02.06 올해 2월에 여자친구와 상하이에 다녀왔습니다. 처음에 중국에 대해 무섭기도 하고 가기 싫었는데, 막상 가보니 되게 좋았어서 남겨봅니다. 여자친구가 중국어를 엄청 잘하기 때문에 편하게 갔다왔지만, 중국 자체에 구글 맵에 정보도 없고, 고덕지도라는 현지 어플 (영어가 없음)만 사용해야해서 중국어를 모르면 좀 힘들 수 있을 것 같아요. 어딜 가든 영어가 하나 없고 중국어로만 적혀있다는 것 빼고는 여행하기 참 좋았습니다~ 중국 상하이여행 정리 지하철 역마다 엄청나게 큰 백화점이 하나씩 있다. 유명하거나 큰 음식점은 대부분 CCTV를 주방에 달아서 외부에서 볼 수 있게 했다. (깨끗) 지하철마다 공안이 짐 검사를 한다. 한국인한테 되게 호의적이고 뭐 하나라도 더 챙겨준다. 모든 것 (어플, 안내판, 메뉴 등등)이 중국어이다. 모든 결제는 알리페이와 같은 온라인 결제이다. 현지 사람들도 소맥을 어디서 들었는지 마신다. 차량의 대부분이 전기차이고 테슬라가

Naver Blog

E-Market #1 - 프로젝트 시작 및 템플릿 자동화 및 CI 스크립트 작성하기

서론 어떤 프로젝트인지 템플릿 자동화 Github Actions를 통한 CI 스크립트 작성 안녕하세요. 오랜만에 블로그 글을 작성하는 것 같습니다! 그동안 CS와 알고리즘 공부하느라 요즘 스프링에 소홀했습니다. 오랜만에 캡스톤에서도 이어서 사용할 프로젝트를 하나 하려고 생각을 했습니다. 어떤 주제를 할까 고민하다가 아주 예전에 블로그 포스팅으로 올렸던 Community 프로젝트의 연장판인 프로젝트가 좋겠다고 생각했습니다. Community 프로젝트의 연장선인 프로젝트를 만들고자 하는 이유는 예전에 만든 프로젝트의 아쉬움과 더불어서 여러가지 기술적 챌린지도 시도해보고, 기존 Community 프로젝트를 블로그에서도 많은 사람들이 참고를 해주셨기 때문에 도움이 될 것 같아서 생각해봤습니다. (기존 프로젝트는 아래 링크를 따라서 쭉 보시면 어떤 프로젝트였는지 확인하실 수 있습니다!) https://github.com/sosow0212/community https://blog.naver.c

Naver Blog

E-Market #2 - 테스트 격리 자동화 등등 여러가지 Helper 추가 및 QueryDSL 및 종속성 변경하기

안녕하세요. 지난 번에 이어서 오늘도 마찬가지로 프로젝트를 진행하기 위한 뼈대를 만들었습니다. 테스트에 도움이되는 Helper 클래스들 추가와 종속성 일부를 변경해봤습니다. 작업물은 아래 PR 링크로 확인하실 수 있습니다! https://github.com/sosow0212/electronic-market/pull/4 feat: 종속성 변경 및 테스트 자동화 유틸 생성 by sosow0212 · Pull Request #4 · sosow0212/electronic-market Summary Querydsl 설정 추가 Spring 3.x에서도 작동되도록 Jasypt 라이브러리 버전 변경 통합 테스트 환경에서 테스트 격리 자동화하는 클래스 추가 영속성 계층 통합 테스트를 위한 테스트 격리 어노테이션 추가 RestDocs prettyPrint와 클래스 명을 자동으로 해주는 기능 추가 컨트롤러 테스트에서 컨텍스트 ... github.com 테스트 격리 자동화 등등 테스트 관련 Helper

Naver Blog

E-Market #3 - 로그인 구현과 고민한 부분, 새로운 목표

안녕하세요. 오늘은 로그인 기능 구현을 진행했습니다. 진행하면서 고민 점들이 몇 가지 있었는데 진행사항과 함께 적어보도록 하겠습니다. 진행한 작업은 아래 링크에서 확인하실 수 있습니다. https://github.com/sosow0212/electronic-market/pull/7 feat: 로그인 기능을 구현한다 by sosow0212 · Pull Request #7 · sosow0212/electronic-market Summary Member 도메인 생성 회원가입 및 jwt 로그인 기능 구현 HandlerArgumentResolver 구현 테스트 및 문서 작성 🏻 More 외부 라이브러리 추가 시에 회원 가입 후 메일 전송이 늦어지는 경우는 어떻게 처리할 지 고민 필요 -> 트랜잭션이 길어지는 문 close #6 github.com Member 도메인 설계 및 Auth 기능 구현 간단 설명 1번 과정을 진행하면서 어떤 고민을 했는지 새롭게 추가하고 싶은 기능과 해결해야할 부

Naver Blog

E-Market #4 - 외부 기능 사용시 트랜잭션 지연 문제를 비동기로 해결해보자

안녕하세요. 지난 번에 이어서 오늘은 가입 메일 처리를 다뤄보았습니다. 먼저 회원가입 시 환영 메일로 쿠폰을 보내게 됩니다. 여기서 문제점은 다음과 같습니다. 회원가입 시 AuthService 와 MailService 참조 문제 (응집도 저하) 이벤트로 분리 시에 회원가입과 메일 전송 기능이 동기처리가 되어서 트랜잭션이 길어지는 문제 만약 외부 기능인 메일 전송 기능이 오래 지연된다면 사용자도 결과를 오래 기다려야한다. 메일을 비동기로 처리한다면 메일 전송이 실패했을 땐 어떻게 재전송을 해야하는지 이런 문제점들을 오늘은 어떻게 해결했는지 작성해보도록 하겠습니다. 틀린 내용이 있을 수도 있다면 댓글로 피드백 부탁드립니다! 작업내용은 아래 링크에서 확인하실 수 있습니다. https://github.com/sosow0212/electronic-market/pull/9 ++ 24.01.19 트랜잭션 전파 설정을 변경하였습니다. https://github.com/sosow0212/2024-e

Naver Blog

E-Market #5 - 게시글 기능 구현과 도메인 서비스로 이미지 처리하기

안녕하세요. 오늘은 사용자들끼리 소통할 수 있는 게시글 기능을 구현했습니다. 게시글에 필요한 기능은 기본적인 포스팅을 할 수 있고, 댓글들과 이미지들 그리고 좋아요 기능이 있어야합니다. 이번엔 [게시글, 이미지] 기능만 구현했고, [좋아요, 댓글]은 따로 구현할 예정입니다. 어떤 고민을 했고, 어떤 식으로 게시글과 이미지를 구현했는지 알아보도록 하겠습니다. 작업한 내용은 해당 링크에서 확인하실 수 있습니다! 틀린 정보는 피드백 부탁드립니다 :) https://github.com/sosow0212/2024-electronic-market/pull/14 feat: 게시판 기능을 구현한다 by sosow0212 · Pull Request #14 · sosow0212/2024-electronic-market Summary Board 테이블 생성 Image 테이블 생성 게시글 기능 구현 🏻 More 이미지 도메인 서비스로 책임 분리 close #11 github.com 고민한 점 사실 이

Naver Blog

[23~24] 크리스마스 우기 나트랑 여행

굉장히 게으름 피우다가 지금 올리는 나트랑 여행기입니다. 여자친구와 12월 중순 크리스마스 포함해서 6박 8일 여행을 다녀왔습니다. 비행기 타는 날에 눈이 많이 와서 비행기 연착이 1시간 되고 저녁 늦은 비행기를 타고 새벽 2시쯤 나트랑에 도착했습니다! 나트랑 깜란 공항에 도착하면 자기 택시 타라고 호갱이 많은데 저희는 그랩으로 택시를 잡았습니다. 근데 지금 생각해보면 큰 차이는 안나지만 시세 제시 했을 때 그랩보다 현지에서 잡는게 더 쌀 수도 있습니다. 시간이 애매해서 0.5박을 하려고 바로 사타호텔가서 잠을 잤습니다! 아침에 일어나자마자 숙소 앞에 있는 해피 스파를 갔는데요. 여기 정말 대박입니다. 저렴하고 엄청 시원한데, 오일로 발 만지시다가 바로 얼굴과 머리도 주물러주셔서 여자친구는 얼굴에 여드름이 많이 났습니다. 그리고 사타호텔 앞에 그릭 수블라키라는 서브웨이 비스무리 한 것이 있는데 진짜 너무 맛있어서 배달로도 3번정도 시켜먹었습니다. 저희가 며칠 묵을 숙소는 나트랑 시내

Naver Blog

E-Market #6 - 동시성 문제를 해결할 수 있는 여러가지 방법과 성능테스트를 바탕으로 적합한 방식 선택하기

안녕하세요. 오늘은 E-Market에서 발생하는 여러 동시성 문제에 대해 어떻게 해결했는지에 과정과 고민을 포스팅 하겠습니다. 단순히 동시성 문제를 해결하는 방법이 아닌 적절한 방식을 선택한 과정에 대해 적도록 하겠습니다. 저와 같은 고민을 하신 분들에게 많은 도움이 되셨으면 좋겠습니다. 해당 글에선 여러가지 동시성 처리 방법에 대해 알아보고 성능 테스트를 통한 프로젝트에 적합한 방식을 선택하는 방법에 대해 기술하였습니다. 먼저 저희 서비스에서는 여러 부분에서 동시성 이슈가 발생하지만 해당 글에서는 간단하게 게시글 좋아요 기능을 바탕으로 설명해보도록 하겠습니다. 목차 1. 동시성 문제가 발생하는 이유와 간단한 도메인 설명 1-1. 동시성 문제가 발생하는 이유 1-2. 간단한 도메인 설명 2. 동시성 제어를 위해 여러가지 시도한 방법들 2-1. 기존 방식 2-2. 트랜잭션 격리 수준 바꾸기 2-3. Update 쿼리를 직접 날려 해결하기 2-4. 낙관적 락을 이용해 해결하기 2-5.

Naver Blog

E-Market #7 - 상품의 조회수 치팅 방지 구현하기

안녕하세요. 일단 기능을 빠르게 구현하고 성능 개선을 진행할 생각인데 할 것이 아직 많이 남았네요.. 지금까지 올라온 PR의 코드는 전반적으로 뼈대코드라고 생각해주시면 될 것 같습니다! 일단 오늘은 상품의 조회수 기능을 구현했습니다. 조회수 증가만을 구현하는 건 쉽지만 부가적으로 신경쓸 부분들이 있었습니다. 만약 한 명이 같은 상품을 반복적으로 들어가면 조회수가 계속 증가한다. (치팅) 많은 사용자로부터 동시 요청이 오면 조회수에서 동시성 문제가 생긴다. 2번은 지난 포스팅에서 다뤘으므로 오늘은 1번 문제를 집중적으로 어떻게 해결했는지 작성해보도록 하겠습니다. 피드백은 언제나 환영입니다 :) 해당 PR 링크입니다. https://github.com/sosow0212/2024-electronic-market/pull/29 feat: 상품의 조회수 기능 및 치팅 방지 기능 구현 by sosow0212 · Pull Request #29 · sosow0212/2024-electronic-m

Naver Blog

E-Market #8 - Infra 1편 : Jenkins를 이용한 CI/CD 파이프라인 구축하기

Infra 시리즈 1편 : Jenkins를 이용한 CI/CD 파이프라인 구축하기 https://blog.naver.com/sosow0212/223369462311 2편: Spring Boot Actuator, Prometheus, Grafana로 모니터링 환경 구축하기 https://blog.naver.com/sosow0212/223369973401 3편: Jenkins 무중단 배포 설정 및 Docker를 이용하여 서버를 띄우도록 CD 방식 변경 https://blog.naver.com/sosow0212/223371181808 안녕하세요. E-market 프로젝트에서 개발이 어느정도 진행이 됐고, 문서화 공유를 위해서 슬슬 배포를 진행해야했습니다. 그래서 어떤 과정으로 배포하였는지 적어보도록 하겠습니다. 1편에서는 Jenkins를 이용하여 빌드하여 Jar 파일을 Prod 서버에 전송하고 실행시키는 과정을 다룹니다. 서버 아키텍처 서버는 AWS EC2 인스턴스를 2대 사용하고, 각각

Naver Blog

E-Market #9 - Infra 2편 : Spring Boot Acutuator, Prometheus, Grafana로 모니터링 환경 구축하기

Infra 시리즈 1편 : Jenkins를 이용한 CI/CD 파이프라인 구축하기 https://blog.naver.com/sosow0212/223369462311 2편: Spring Boot Actuator, Prometheus, Grafana로 모니터링 환경 구축하기 https://blog.naver.com/sosow0212/223369973401 3편: Jenkins 무중단 배포 설정 및 Docker를 이용하여 서버를 띄우도록 CD 방식 변경 https://blog.naver.com/sosow0212/223371181808 지난 포스팅에 이어서 오늘은 모니터링 환경 구축을 진행했습니다. 목차 모니터링 하는 이유 모니터링 방법과 아키텍처 설정 방법 1. 모니터링을 하는 이유 우리가 서버를 모니터링을 하는 이유는 여러가지가 있을 수 있습니다. 먼저 저 같은 경우는 주기적인 배치 작업을 진행하면서 데이터 처리를 하기 위해 서버에서 메모리에 데이터들을 올려놓고 처리하는 기능들이 있습니다

Naver Blog

[우테코] 레벨3 3주차 생활기

안녕하세요. 벌써 레벨 3이 시작되고 3주가 지났습니다. 그 사이에 첫 번째 데모데이도 잘 마쳤고, 피드백을 바탕으로 부족한 부분은 설문조사도 하고 회의도 하면서 팀의 방향성 또한 잘 잡혀져 가는 것 같습니다. 레벨 3에 오면서 느낀 점은 미션이 사라지고, 프로젝트를 진행하는 과정에서 스스로 모든 것을 직접 확인해보면서 개발을 해야해서 자유롭지만 그만큼 책임을 져야한다는 점입니다. 또한 지금은 리뷰어가 아닌 크루들끼리 코드리뷰를 하면서 개발을 진행하고있는데요. 저 또한 누군가에게 리뷰어가 되기도 하는 이런 상황에서 얕은 지식을 바탕으로 리뷰한다면 상대에게는 큰 도움이 되지 않을 것 같습니다. 결국 개발과 코드리뷰 모두 크루들의 재량으로 이뤄지기 때문에 더욱 깊은 공부를 할 필요가 있다고 느꼈습니다. 정해진 가이드라인이 없어지다보니 지금까지 어영부영하기도 하고 한 부분에 집중하지 못하고 여러가지를 얕게 보고 공부했습니다. 이런 방법으로는 한계가 있다고 생각이 드는 한 주였습니다. 단순

Naver Blog

우테코 Car-ffeine #4 - 카페인 팀의 CI/CD

안녕하세요~ 카페인 팀의 제이입니다. 오늘은 저희 팀에서 CI/CD는 어떻게 진행되는지 작성하겠습니다. https://github.com/woowacourse-teams/2023-car-ffeine GitHub - woowacourse-teams/2023-car-ffeine: 실시간 전기자동차 충전소 지도 및 사용 통계 조회 서비스️ 실시간 전기자동차 충전소 지도 및 사용 통계 조회 서비스️. Contribute to woowacourse-teams/2023-car-ffeine development by creating an account on GitHub. github.com CI (지속적 통합) 카페인 팀에서는 지속적 통합 즉 CI를 진행하기 위해서 위에 사진과 같이 Github Actions를 사용합니다. main, develop 브랜치에 Push, Pull Request 요청이 들어간다면 이벤트가 발생하고, Github Actions를 통해 저희가 작성해둔 스크립트가 실행

Naver Blog

우테코 Car-ffeine #5 - 필터링 기능 구현과 인덱스 이용한 조회 속도 개선하기 - 1

안녕하세요~ 우테코 카페인 팀의 제이입니다. 오늘은 필터링 기능 구현 및 인덱스를 이용한 조회 속도 개선하는 작업을 진행했습니다. 모든 코드는 아래 팀 깃허브에서 확인하실 수 있습니다. https://github.com/woowacourse-teams/2023-car-ffeine/pull/218 feat: 서버에서 충전소 정보들을 필터링 하는 기능을 만든다 by sosow0212 · Pull Request #218 · woowacourse-teams/2023-car-ffeine Summary 충전기 필터링 기능 구현, 인덱스 설정, 몇 가지 객체 추가를 했습니다. ️ Actual Time of Completion 🏻 More 현재 좌표에 해당하는 전체 충전소를 조회하는 기능에 필터링 기능이 추가 되었습니다. 필터는 [충전소 회사 이름, 충전 타입, 충전 용량] 으로 세 가지입니다. JPQL로 2^3 = 8개의 ... github.com 요구 사항과 기능 구현 목록 카페인 팀은 전

Naver Blog

[우테코] 3차 데모데이까지

정말 정신 없이 보내고 있는 하루입니다. 최근에는 바쁘다는 핑계로 회고록을 작성하지 못했습니다. 2월 우테코 시작부터 회고록을 매주 빼먹지 않고 썼는데, 역시 한 번 빼먹을 땐 어려웠지만 그 다음부터는 쉬운 것 같습니다. 벌써 3차 데모데이까지 마무리가 되었습니다. 우테코에 들어오고나서부터 가장 바빴고, 가장 빠르게 지나간 레벨이 있다면 지금인 것 같습니다. 방향이 잡히지 않았던 초반에 비해서 지금은 비교적 어떤 것을 학습할지 방향이 잡힌 것 같습니다. 요즘은 데이터베이스 공부를 주로 하고 있습니다. 예전에는 이해를 못해서 "언젠가 미래의 내가 하겠지"라고 생각하고 넘겼던 것들을 모두 지금 하고 있습니다. 성장을 했고 용어를 알아듣는다는 소리겠죠? 그렇게 재미 없었던 데이터베이스가 또 하다보니깐 재밌는 것 같습니다. 락과 인덱스에게 매일매일 부셔지고 있지만, 언젠가는 큰 힘이 될 걸 알기에 열심히 하고 있습니다. 카페인 팀의 프로젝트도 잘 만들어가고 있는 것 같고, 매주 새로운 토픽

Naver Blog

[우테코] 이번 주 개발 일기

벌써 다음주면 레벨3가 끝납니다 정말 시간은 왜이리 빨리 갈까요? 저희 팀은 이번 주에 모든 기능 구현을 완료하자고 얘기를 했습니다. 그래서 이번 스프린트에서 제가 구현한 부분에 대해서 간단하게 작성해보고자 합니다. 이번에 저희는 사용자 개인화가 필요해서 크게 세 가지의 기능을 만들었습니다. 존재하는 전기차 차량 등록 및 유저의 차량 선택 기능 구현 전기차 별로 기본 필터 값을 세팅하는 기능 구현 사용자가 원하는 커스텀 필터셋 기능 구현 https://github.com/woowacourse-teams/2023-car-ffeine/pull/464 feat: 차량 관리 기능과, 유저의 차량을 등록할 수 있는 기능을 구현한다 by sosow0212 · Pull Request #464 · woowacourse-teams/2023-car-ffeine Summary 차량 개인화를 위해 Car 테이블을 만들었습니다. 차량 정보는 어드민 페이지에서 추가할 수 있습니다. 또한 차량에 해당하는

Naver Blog

우테코 Car-ffeine #6 - EC2 서버 추가와 동시에 Dev, Prod 환경 분리하기

안녕하세요. 카페인 팀의 제이입니다. 오늘은 저희가 EC2 인스턴스를 받으면서, 어떻게 dev, prod 배포 환경을 분리했는지 적어보려고 합니다. 기존 카페인 팀의 EC2 구조는 여기서 보실 수 있습니다. 기존 상황과 문제점 카페인 팀에서는 기존에 3대의 EC2 인스턴스가 있었습니다. 각각 [infra, dev, db] 역할을 하는 인스턴스로 존재하고 있었습니다. 저희는 release 브랜치를 통해 dev서버에 배포를 한 후 검증이 된다면, 실제 사용자들이 사용하는 prod 서버에 배포하고 있습니다. 문제는 기존의 3대의 인스턴스 중에서 dev 서버에 있었습니다. 기존 dev 서버는 총 4개의 서버를 배포하고 있었고 배포하는 서버는 다음과 같습니다. [prod-BE, prod-FE, dev-BE, dev-FE] 그리고, 기존 dev 서버에서는 환경을 분리해주기 위해서 Nginx를 통해서 포트 포워딩은 다음과 같이 해주었습니다. prod-BE = 8080 prod-FE = 3031

Naver Blog

[우테코] 레벨 3가 마무리 하면서

지난주에 우테코 레벨 3가 마무리 되었습니다. 원래 같았으면 바로 회고록을 작성했을 것 같지만, 다른 일이 있어서 바로 작성하지 못했습니다. 우테코를 들어올 때 가장 기대했던 프로젝트가 끝났습니다. 레벨 3 기간을 저는 가장 기대 했었습니다. 막상 지금 이 시기에 오니깐 그때는 보지 못했던 기술적인 것들도 있지만, 그래도 지금 생각해보면 작년에 비해 매우 빨리 저는 많이 성장한 것 같습니다. 기술적인 깊이로도, 튜닝할 게 보이는 지금 시각으로서도 엄청 많이 성장한게 느껴집니다. 단순히 누군가 공부를 시켜서 그런 것이 아닌 같은 크루들과 열심히 해서 배운 것도 많고 시각이 넓어진 것이겠죠. 작년에 저는 단지 이런 모든 것이 우테코만 들어가면 해결 되는 줄 알았고, 우테코만 들어가면 이렇게 되는 줄 알았습니다. 지금 생각해보면 그때 한 생각은 건방진 생각인 것 같습니다. ㅎㅎ 다시 생각해보면 좋은 크루들 덕분이 아닐까요? 전반적으로 다들 열심히하는 좋은 환경 덕분에 지금 보면 많이 성장

Naver Blog

우테코 Car-ffeine #7 - 혼잡도 조회 속도를 개선해보기

안녕하세요. 카페인 팀의 제이입니다. 저희 서비스에서는 충전소의 요일과 시간대 별로 충전소 혼잡도 정보를 제공을 차별적인 기능으로 제공하고 있습니다. 이를 구현하기 위해서 공공 데이터에서 정보를 수집하고있습니다. 혼잡도를 조회하기 위해서는 약 23만 건의 충전소 * 7일 * 24시간 * 2(급속, 완속) = 약 8000만 건의 데이터 중에서 조회를 하는 형식으로 되어있습니다. 너무 많은 데이터가 있다보니 조회 속도가 많이 느린데요. 오늘은 이를 어떻게 개선했는지 작성해보도록 하겠습니다. 참고로 해당 글의 성능 측정에 이용한 데이터의 수는 약 20만 건입니다. 저희 서비스 코드는 아래 깃허브에서 보실 수 있습니다. https://github.com/woowacourse-teams/2023-car-ffeine GitHub - woowacourse-teams/2023-car-ffeine: 실시간 전기자동차 충전소 지도 및 사용 통계 조회 서비스️ 실시간 전기자동차 충전소 지도 및 사용

Naver Blog

우테코 Car-ffeine #8 - 서비스를 직접 써보고 개선해보기

안녕하세요! 카페인 팀의 제이입니다. 카페인 서비스를 배포를 하고 여러 사이트에 홍보를 많이했습니다. 첫 번째 배포 후 초기 피드백은 느리다는 점이었고, 이 부분은 프론트와 함께 작업을 하며 실사용이 가능한 정도로 개선을 했고, 다시 한 번 홍보 후에 피드백을 받았습니다. 두 번째 피드백에서는 저희가 예상하지 못한 부분들도 많이 있었습니다. 사용자 관점을 많이 고려하고 만들었다고 생각해도 그러지 못했던 것 같습니다. 아무래도 저희는 전기차주가 아니기 때문에 실질적인 사용자 입장에서의 불편함과 어려움을 알 수 없었던 것 같습니다. 저희 팀은 개발자 관점이 아닌 사용자 입장에서 경험을 해보고자 짧은 전기차 여행을 다녀왔습니다. 짧은 전기차 여행이었지만 어떤 부분을 느꼈고, 어떻게 개선을 하고자 하는지 작성해보도록 하겠습니다 해당 글은 짧은 여행기와 개선기를 다루고 있습니다. 전기차 이용 시나리오와 여행기 및 서비스의 문제점 파악하기 익숙한 지역이 아닌 타지역을 목적지로 설정 목적지 근

Naver Blog

우테코 Car-ffeine #9 - 카페인 팀의 무중단 배포

안녕하세요! 카페인팀의 제이입니다. 저희 카페인 팀에서 무중단 배포를 진행했습니다. 어떤 과정으로 진행을 했는지 작성해보도록 하겠습니다! 기존 배포 방식과 문제점 먼저 카페인 팀의 기존 배포 방식은 다음과 같습니다. Target branch에 push가 되면 Github Actions가 작동합니다. Target branch의 소스 코드가 빌드되어서 Docker Hub에 올라가게 됩니다. Github Actions의 self-hosted runner를 통해 infra 서버에서 prod 서버로 접근하여서 기존에 띄워진 서버를 다운 시킵니다. Docker Hub에 업로드한 Docker image를 pull해서 서버를 가동시킵니다. 이런 과정으로 배포 스크립트가 작성되어 있습니다. 하지만 이 방법은 기존 서버를 다운 시키고 새로운 서버를 띄울 때 다운 타임이 존재한다는 문제점이 있습니다. 사용자 입장에서는 잘 사용하고 있는데 갑자기 서비스가 작동되지 않는다면 서비스에 대한 신뢰성이 낮아질

Naver Blog

[우테코] 뒤늦은 레벨 4 마무리 회고록과 전환 면접

우아한테크코스의 거의 마무리 단계인 레벨 4가 마무리 되었습니다. 레벨 4 기간동안은 프로젝트 리팩토링 기간이었습니다. 하지만, 레벨 3과 다르게 프로젝트를 진행하는 건 팀바팀의 자율이었고 그보다는 미션들을 위주로 진행했던 시간이었습니다. 톰캣, MVC, JDBC라이브러리 구현에 이어서 레거시 코드 리팩토링 미션까지 너무나도 재밌게 수행했던 기간이었습니다. 특히 레거시 코드 리팩토링 미션에서는 의존성 분리 기법도 많이 배울 수 있었고 리뷰이였던 테오 덕분에도 많이 배울 수 있어서 진짜 재밌게 공부했던 것 같습니다. 그리고 미션 외에도 최종 데모데이가 끝나면서 카페인 팀의 프로젝트도 마무리가 되었습니다. 카페인 편리한 전기차 충전소 지도 carffe.in 프로젝트를 통해서 너무나도 많은 것을 배웠고, 팀원들 덕분에 재밌게 진행해서 기억에 많이 남을 것 같습니다. 레벨 4가 끝나고 본격적으로 레벨 5인 취업 기간을 맞이했습니다. 졸업이 남아있기에 전환 면접을 내년으로 미뤘습니다. 미루면

Naver Blog

[우테코] 우아한테크코스 수료

작년 이맘쯤 최종 코딩테스트를 봤던 게 새록새록 한데 벌써 수료를 했습니다. 사실 수료는 2주 전쯤 했지만, 귀차니즘으로 오늘에서야 블로그를 작성하게 됐습니다! 약 1년 동안 우아한테크코스 활동을 하면서 정말 너무 많은 것을 배울 수 있었습니다. 클린코드, 테스트, 객체지향, 성능 개선 등등 좋은 교육 환경에서 다양한 사람들과 공부를 할 수 있고 프로젝트를 같이 한 경험들은 너무 소중했고 이로 인해 큰 성장을 했다고 생각합니다. 레벨 1,2 때 미션하느라 새벽까지 키보드를 뚜드렸던 것도, 데일리 미팅을 진행했을 때에도, 점심마다 팀원들과 커피 내기를 한 것도 너무나도 즐겁게 공부하고 재밌었던 한 해였습니다. 예전에 다른 기수의 수료 포스팅들을 보고 언젠가 나도 쓸 수 있을까 라는 생각을 많이 했었습니다. 그런 생각이 이뤄져서 오늘에서야 수료 포스팅을 작성할 수 있어서 기분이 싱숭생숭 합니다 협력 🏻️ 우테코에서 가장 좋았던 문화였습니다. 미션에서 페어 프로그래밍을 진행하면서 정말

Naver Blog

[배포] 스프링 서버를 배포 및 쉘 스크립트로 최신화 및 배포 자동화 해보기 (https, nginx)

안녕하세요. 최근에 우테코에서 미션을 하면서 배포를 했는데, 오늘은 배포 과정에 대해 적어보도록 하겠습니다. 대략적인 목차는 다음과 같습니다. EC2 인스턴스 생성 - ubuntu (생략) EC2 서버 설정 쉘 스크립트 작성 (배포 자동화) 도메인 발급 SSL 인증서 발급 & Nginx로 서버 Https 설정하기 스프링 서버 CORS 설정 EC2 인스턴스 생성하기 (이 부분은 자료가 많기에 짧게 설명하고 넘어가겠습니다! 진행은 ubuntu 22.0.4 기준) EC2 인스턴스를 생성해줍니다. https://blog.naver.com/sosow0212/222832944678 [AWS] EC2 서버 임대 및 Mac으로 접속하기 / EC2 서버와 방화벽 [AWS] EC2 서버 임대 및 Mac으로 접속하기 / EC2 서버와 방화벽 AWS EC2 서버 임대하기 AW... blog.naver.com (참고) 서버나, 옵션은 개인에 맞게 선택합니다. EC2 서버 설정 EC2 서버로 들어와서 Tim

Naver Blog

[개발 일기 #30] 5월의 개발 공부 : 협업과 6월의 계획

벌써 5월도 끝이 났네요. 이번 달은 정말 빠르게 정신없이 지나간 것 같습니다. 여러가지 미션을 하면서 적용해본 기술들도 많고 새로운 것들을 정말 많이 배웠습니다. 하지만 아직은 사용법만 알고, 깊이 있게 공부하지 못한 것들이 조금 쌓여있어서 하나하나 공부하려고 계획하고 있습니다. 5월달에는 우테코에서 지하철 미션과 함께 장바구니 협업 미션을 진행했습니다. 장바구니 미션은 프론트엔드 크루들과 같이 진행했는데 되게 재밌었습니다. 다만 저는 2차 미션 진행 기간동안은 예비군이 잡혀서 가장 중요할 때 정작 참여하지 못해서 팀원들에게 많이 미안했습니다 ㅠ.ㅠ 배포를 하면서 배포 스크립트도 처음 작성해보고, 웹 엔진도 공부하고 정말 많은 것을 배운 것 같습니다. 뭔가 타 분야를 공부하는 느낌이랄까 저에게 배포는 개발과는 살짝 다른 느낌으로 다가오는 것 같습니다. 그래도 재미있게 진행해서 기분 좋은 경험이었습니다. 6월에는 약 2주간 우테코에 출근하지 않기 때문에, 어떤 것을 공부할지 계획을

Naver Blog

[우테코] 레벨2 7~8주차 회고록 - 장바구니 협업 미션 피드백 정리

7~8주차는 한 번에 올리게 됐습니다. 이번 장바구니 미션은 프론트엔드와 협업으로 진행했습니다. 따라서 1단계 미션에서는 뼈대코드 분석 및, CORS 에러를 해결하고 서버를 배포하는 것이 목표였습니다. 배포 과정에서는 CI/CD를 고려하기도 했고, 여러가지 로깅을 위한 전략을 택해보기도 했습니다. 굉장히 유익했던 것 같습니다 :) 2단계 미션은 이제 재화 관련 기능을 추가하는 건데, 이 미션을 진행하면서 받은 피드백을 정리해보도록 하겠습니다. https://github.com/woowacourse/jwp-shopping-order/pull/9#event-9465035836 [2단계 - 주문 기능 구현] 제이(이재윤) 미션 제출합니다. by sosow0212 · Pull Request #9 · woowacourse/jwp-shopping-order 안녕하세요 웨지! 먼저 이번 2단계 미션 진행 기간이랑 예비군 기간이 겹쳐서 상대적으로 느릴 수 있는 점 양해 부탁드리겠습니다! 그래도 최

Naver Blog

[우테코] 레벨2 회고록과 성장일기, 그리고 늦게 올리는 테코톡 후기 및 영상

벌써 우테코 레벨2가 마무리 됐습니다. 전체 기간 중에 절반이 지나갔는데 참 빠른 것 같습니다. 저번에도 레벨 인터뷰가 마치고 뜬 시간에 레벨1 회고록을 쓴 것이 생각나네요. 이번 레벨 인터뷰는 저번과 다르게 말도 제대로 했고, 개선된 모습으로 인터뷰를 진행해서 마음이 편합니다. 하여튼 메타인지의 중요성을 이번에도 느끼게 됐고, 말하는 연습을 했던 게 도움이 됐음을 느꼈습니다. 테코톡 테코톡 발표는 레벨 1때 했고, 영상은 레벨 2 초반에 올라왔는데, 그땐 너무 바빠서 회고를 하지도 못했습니다. 지금이라도 남겨봅니다.. ㅎㅎ 테코톡은 레벨 1 기간 초반에 진행했습니다. 처음에는 테코톡을 빠르게 하고 끝내자라는 생각도 있었고, 마침 주제가 '단위 테스트'였어서 바로 선정했습니다. 공교롭게도 발표 날짜를 보니 제가 전체 백엔드 크루 중에서 첫 순위로 발표를 하게 됐습니다. 그냥 10분동안 자유롭게 주제에 대해서 발표를 하면 되는데 이게 준비 과정에서 참 막막했습니다. 크루들은 발표 시점

Naver Blog

Chat-Univ API Server #1 - 기획과 Auth API 작업

프로젝트 기획 최근에 프로젝트를 하나 해야겠다고 생각을 했습니다. 여러가지 기능이 있지만, 일단 한 문장으로 정리하자면 대학교를 대상으로 실시간 검색어 및 여러가지 기능을 제공하는 서비스입니다. 나중에 자세히 올리겠지만, 여러 대학교를 대상으로 진행하는 프로젝트인만큼 적지만 그래도 트래픽은 받을 수 있을 거라고 생각합니다. (사실 희망입니다 ㅠ.ㅠ) 서버 API쪽은 제가 리드를 하면서 학과 동기 3명을 구했습니다. 친한 친구들인데 같은 방향으로 성장하고 있어서 이번 프로젝트로 같이 성장했으면 좋겠습니다~ 그리고 프론트엔드 서버 개발하시는 분들은 예전에 같이 프로젝트한 형의 소개로 같은 학교에 다니시는 3분을 구했습니다. 전반적인 기획과 리드를 하기 때문에 설레기도 하지만 한편으로는 부담감도 있습니다. 그래도 많은 성장을 할 수 있을 것이라고 생각해서 열심히 해보려고 합니다. 어떻게 개발 할까요? 1. 서로 무조건 존중하는 분위기로 진행하기로 했습니다. 2. 우테코에서 코드리뷰로 정말

Naver Blog

Chat-Univ API Server #2 - Member API, Board API, 테스트 중복 제거, 코드 리뷰

안녕하세요. 사이드 프로젝트로 진행하고 있는 Chat-Univ API Server에서 최근에 Member & Board API를 추가했습니다. 또한, Conflict 방지를 위해 도메인 별 Exception과 Handler 관리 및 Mock 테스트 중복 코드 제거를 했습니다. 이에 대해 간단하게 다뤄보도록 하겠습니다. 이번주차까지는 몸풀기 단계로, 간단한 API를 구현하며 같이 진행하는 친구들의 코드 리뷰를 중심으로 하고 있고, 뼈대를 튼튼하게 하고 있다는 정도로 봐주시면 될 것 같습니다. 먼저 Github 레포지토리 주소입니다. 누구든 코드 리뷰 및 피드백은 환영입니다 :) https://github.com/sosow0212/ChatUniv GitHub - sosow0212/ChatUniv: (2023~) GPT를 활용한 대학생들을 위한 서비스 (2023~) GPT를 활용한 대학생들을 위한 서비스. Contribute to sosow0212/ChatUniv development b

Naver Blog

[우테코] 레벨3 1주차 회고록 - 프로젝트 시작 및 정리

안녕하세요. 우테코 레벨3가 시작되면서 기다리던 팀 프로젝트가 시작되었습니다. 프로젝트에 배정되는 팀은 랜덤입니다. 제가 배정된 팀은 전기차 관련 데이터를 다루는 크루 가브리엘의 팀입니다. 하고싶은 주제를 투표할 때 몇몇 후보들 중 하나가 이 주제였는데, 원하는 팀에 들어가서 다행이라고 생각합니다. 이번 프로젝트의 큰 장점은 많은 데이터들을 다룬다는 것입니다. 공공 API에서 다량의 전기차 충전소 데이터들을 받아와서, 그로 통계도 내고 여러가지를 할 수 있습니다. 요청에서 조회가 이뤄지는 부분이 많다보니 데이터베이스 최적화와 성능 개선을 할 수 있는 프로젝트이고, 그런 점에서 다른 프로젝트에서는 쉽게 경험없기 때문에 재밌을 것 같습니다. 팀원들도 좋아서 정말 다행이고, 큰 불협화음 없이 진행될 것 같습니다. 팀 레포지토리 https://github.com/woowacourse-teams/2023-car-ffeine GitHub - woowacourse-teams/2023-car-ff

Naver Blog

우테코 Car-ffeine #1 - 큰 틀에서 바라보는 서버 아키텍처 계획

https://car-ffeine.github.io/4 큰 틀에서 바라보는 서버 아키텍처 계획 | CAR-FFEINE 서론 car-ffeine.github.io 서론 안녕하세요 우테코 카페인 팀의 제이입니다. 회의를 하면서 이번 주 제가 맡은 파트는 서버 인프라입니다. 아직은 EC2 스펙과 데이터들이 정확히 나오진 않았지만, 우테코에서 적은 EC2 스펙을 제공한다는 기준으로 계획도를 적어볼 생각입니다. 상황 인식 예상하는 상황은 다음과 같습니다. API의 데이터를 다루는 상황에서 최소 약 150만 건에서 최악 약 3700만 건의 데이터를 다룹니다. 이전 기수를 봤을 때 EC2의 개수는 많이 받은 것으로 파악 됐습니다. (이 부분은 달라질 수 있습니다.) 상황에 따라서 공공 API를 업데이트 해주는 서버와, 제공 서버를 나눌 수 있습니다. 깃허브에서 Conflict가 나지 않기 위해서 안정적인 검증을 거친 후 Merge를 해야합니다. 프로젝트의 버전이 갱신된다면 EC2 서버에서 자동으

Naver Blog

우테코 Car-ffeine #2 - 23만 건의 데이터를 받아서 저장하는 과정을 최적화 해보자

안녕하세요. 우테코 카페인 팀의 제이입니다. 저희 서비스에서 필연적으로 해야하는 과정이 있습니다. 바로 공공 API에서 데이터를 받아오고 데이터베이스에 저장하는 것입니다. 공공 API에서는 한 페이지당 최대 9,999개의 데이터를 제공하고, 이를 23번 정도 반복해야합니다. 따라서 데이터의 양은 총 약 23만 건 정도 되고, 오늘은 이 데이터를 DB에 저장하는 과정을 최적화하는 과정을 다뤄보겠습니다. 저희 팀은 4인 페어로 진행하면서 기본적인 방법부터 여러 가지를 적용했는데요. 어떻게 유의미한 속도로 바뀌었는지 작성해보도록 하겠습니다. (with. 누누, 박스터, 키아라) 같은 팀의 크루 누누의 글을 참고 했습니다! 테이블 구조 간단 설명 최적화 과정에 앞서 저희 서비스의 테이블의 구조를 간단하게 설명하겠습니다. 저희는 전기차 충전소를 다루는 도메인이기 때문에, 다음과 같은 테이블로 구성되어있습니다. 충전소 충전소에 속한 충전기들 조회시에 충전소와 충전기들의 데이터 모두가 필요해서

Naver Blog

Chat-Univ API Server #3 - 통합 테스트 환경에서 테스트 격리와 테이블 초기화 자동화하기

안녕하세요. 오늘은 사이드 프로젝트로 제작하고 있는 Chat-Univ 프로젝트에 테스트 격리를 진행했습니다. 우테코에서 진행하고 있는 Car-ffeine 프로젝트에도 적용하고자 미리 시도를 해봤습니다. 코드는 아래에서 확인하실 수 있습니다. https://github.com/sosow0212/ChatUniv/tree/feat/test-separation {"payload":{"allShortcutsEnabled":false,"path":"","repo":{"id":650064466,"defaultBranch":"master","name":"ChatUniv","ownerLogin":"sosow0212","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2023-06-06T09:00:32.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/6321348.

Naver Blog

우테코 Car-ffeine #3 - 주기적인 데이터 요청으로 받은 데이터를 효율적으로 업데이트 및 삽입하기

안녕하세요~ 우테코 카페인 팀의 제이입니다. 오늘은 카페인 팀의 프로젝트를 진행하면서 어떤 문제를 겪고 해결했는지 적어보도록 하겠습니다. * 배우는 단계이다 보니 틀린 부분이 있을 수 있는데, 피드백 부탁드립니다 :) https://github.com/woowacourse-teams/2023-car-ffeine GitHub - woowacourse-teams/2023-car-ffeine: 실시간 전기자동차 충전소 지도 및 사용 통계 조회 서비스️ 실시간 전기자동차 충전소 지도 및 사용 통계 조회 서비스️. Contribute to woowacourse-teams/2023-car-ffeine development by creating an account on GitHub. github.com 먼저 글을 쓰기 전에 문제 상황에 대해 간단하게 말씀드리겠습니다. 문제 상황 카페인 팀에서는 전기차 충전소 공공 API를 활용하여 충전소의 혼잡도 제공 및 여러 서비스를 제공합니다. 이런 서비

Naver Blog

[Spring] Rest Docs로 API 문서를 관리해보자

백엔드 서버 개발을 하다보면 API 명세서를 관리할 일이 생깁니다. 누군가 우리의 서버 API 명세서를 보고 개발을 할 수도 있고, 추가적인 혹은 제거할 기능을 문서를 보고 결정하기도 합니다. 따라서 문서를 최신화하면서 관리해주는 것은 중요한데요. 오늘은 이 문서 관리를 할 수 있는 Rest Docs에 대해 알아보겠습니다. Rest Docs 알아보기 전에 Swagger vs RestDocs 자바 진영에서 문서 관리할 수 있는 방법은 많지만, 크게 Swagger, Rest Docs 이렇게 두 가지를 많이 사용하는 것 같습니다. Rest Docs와 Swagger의 차이점을 한 번 간단하게 알아보고 Rest Docs 설명으로 넘어가도록 하겠습니다. Swagger 스웨거는 위에 사진과 같이 어노테이션을 추가해주면서 문서를 만들어줄 수 있습니다. Rest Docs와 다르게 간단하게 어노테이션만 추가해주면 자동으로 문서가 생성되기 때문에 큰 시간을 들이지 않고 문서화를 할 수 있습니다. 하지만

Naver Blog

[우테코] 레벨2 6주차 회고록 - 지하철 미션 2단계 (Event, Cache으로 성능 개선하기 / LifeCycle)

늦은 6주차 회고록입니다. 6주차에는 지하철 미션 2단계를 진행했습니다. 다익스트라 라이브러리를 이용해서 역과 역 사이의 최단 경로를 반환해주는 API가 추가 되었습니다. https://github.com/woowacourse/jwp-subway-path/pull/113 [2단계 - 경로 조회 기능] 제이(이재윤) 미션 제출합니다. by sosow0212 · Pull Request #113 · woowacourse/jwp-subway-path 에단 안녕하세요! 제이입니다. 이번 step2를 진행하면서 최단 경로를 찾는 API를 구현하였습니다. 먼저 처음에는 최단 거리에 해당하는 역들만 출력해주었습니다. ex. 잠실역, 잠실새내역, 종합운동장역 .. 하지만, 사용자들에게 역 이름만 반환해준다면, 환승 정보를 알기 힘들고, id 값으로 역 조회 같은 기능도 구현할 수 있다고 생각해서 "stat... github.com 성능 개선 이야기 이번 미션에서는 다음과 같은 문제점이 있었습니다.

Naver Blog

[Spring] Filter & Interceptor 에 대해서 알아보자

안녕하세요. 오늘은 Filter와 Interceptor에 대해 알아보겠습니다. 먼저 이 둘은 모두 웹 애플리케이션에서 요청과 응답을 처리하는 데 사용하는 개념입니다. 모두 요청과 응답을 가로채서 특정 작업을 수행하고, 원래 흐름으로 보내주는 역할을 합니다. 요청과 응답을 가로챈다고 했는데, 그렇다면 모든 요청에 대한 보안, 로깅, 인증 & 인가 같은 작업에 수행할 수 있겠죠? 이 내용을 알고 학습을 하면 더 도움이 될 것 같습니다! Filter & Interceptor 흐름 먼저 아래 그림을 살펴보겠습니다. 망나니개발자 블로그 참고해서 다시 그렸습니다. 이 그림을 보면 Filter와 Interceptor가 언제 작동하는지 유추할 수 있습니다. Client 요청 --> WebContext[Filter] --> Interceptor --> SpringContext[DispatcherServlet] 이 순서대로 작동을 하게 됩니다. 그렇다면, Filter는 WebContext 안에서 Sp

Naver Blog

[Spring] @SpringBootTest 알아보기

스프링 테스트를 만들다보면, @SpringBootTest 라는 테스트 어노테이션을 쓰게 됩니다. 통합 테스트를 사용하기 위해 자주 쓰는 어노테이션이지만, 제대로 정리한 적이 없어서 이번 기회에 정리하고자 합니다. 스프링에 여러 테스트에 대해 간단하게 설명드리고, @SpringBootTest에 대해 자세히 알아보도록 하겠습니다. 서론 스프링 여러 테스트에 대해 스프링에서 테스트의 종류는 여러가지가 있지만, @SpringBootTest 어노테이션은 주로 실제 환경처럼 세팅을 해서 우리가 구현한 기능들이 제대로 작성하는지 테스트하기 위해서 사용됩니다. 여기서 한 가지 의문이 들 수 있습니다. @SpringBootTest말고, @WebMvc나 @ExtendWith(Mockito.class)등등으로도 기능을 검증할 수 있지 않나요? 맞는 말입니다! 모두 다 기능 검증은 할 수 있지만, @SpringBootTest와 위에서 언급한 어노테이션의 다른 점이 하나 있습니다. 먼저 @SpringBoo

Naver Blog

[개발 일기 #29] 4월의 개발 공부 : 우테코와 학습 고도화

뒤늦게 올리는 4월의 개발 회고록입니다! 매주 공부 복습 및 학습 내용을 공유하고자 올리는 우테코 회고록도 올리고, 개인적인 월별 회고록도 올리고 슬슬 헷갈리기 시작했습니다 우테코에 들어오고 나서는 모든 공부를 우테코 내부에서 하는 활동과 더불어서 관련 주제를 학습해서 우테코 회고록과 개인 회고록과 크게 다른게 없는 것 같습니다! 이제는 스스로의 약속과 같은 1일 1커밋은 진행 중입니다. 뭐 사실 이게 취업이나 이런 것에 있어서 크게 도움 되는 것도 아니지만, 이를 지키고자 노는 날에도 조금은 공부해야겠다는 생각은 들어서 좋은 것 같습니다. 거의 2년이 되어가는데 정말 하루도 빠지지 않고 꾸준히 했음에 이번 달은 뭔가 스스로에게 더 감사함을 느끼게 되네요. 1일 1커밋에 강박이 생기는 순간 안 하면 스트레스를 받지만 그만큼 무엇이라도 하게 돼서 양날의 검 같다고 느껴집니다. 학습 내용 노션에 체크한 이번 달 학습한 내용입니다. 스프링 DI, IoC JDBC Template Resp

Naver Blog

[우테코] 레벨2 4주차 회고록 - 장바구니 웹 미션 2단계 리뷰 정리

2단계 미션도 성공적으로 끝났습니다. 이번 미션에서는 Domain VS Entity에 대한 고민이 가장 컸던 것 같습니다 :) PR링크 https://github.com/woowacourse/jwp-shopping-cart/pull/262 [2단계 - 상품 관리 기능] 제이(이재윤) 미션 제출합니다. by sosow0212 · Pull Request #262 · woowacourse/jwp-shopping-cart 시카, 안녕하세요? 리뷰이 제이입니다! 이번 미션을 진행하면서 다음과 같은 고민을 겪었습니다. (step1 포함) 도메인 사용에 대해 먼저 Product, Member, Cart 객체를 도메인으로 만들었습니다. 이번 미션에서 사실 "도메인이 필요할까?"라는 생각을 많이 했습니다. 데이터베이스에 저장되는 구조와 같다보니 이런 고민이 들었던 것 같습니다... github.com 2차 피드백 정리 Q. Service 레이어에서 다른 Service를 불러다 쓰는게 좋을지, 아니면

Naver Blog

[IntelliJ] 사용하지 않는 변수, 메서드와 Import를 찾아보자

우테코 미션을 하면서 "사용하지 않는 메서드네요."라는 피드백을 많이 받았습니다. 미션 리팩토링을 하면서 쓰이지 않는 메서드와 변수가 생기는데 이를 잘 확인하지 못했기 때문입니다. 그래서 오늘은 IntelliJ를 사용하는 분들이 알면 좋은 꿀팁을 가져왔습니다. 사용하지 않는 변수와 메서드, 성능 개선점을 찾아보자 Shift 두번을 눌러 네비게이션바를 띄운 상태에서 'Insepect Code"를 눌러줍니다. 그리고 Analyze를 눌러줍니다. 분석이 끝나면 위와 같이 뜹니다. 이제 여기서 [빈 메서드, 사용하지 않는 변수 및 메서드, 미사용 import, 성능 개선점, 오타, 보안 경고] 이렇게 찾을 수 있습니다. 리팩토링 하신 다음에 한 번씩 해주면 좋겠죠?! 커밋할 때 미사용 Import를 자동 제거하기 커밋하기 전에 커밋하는 파일에 해당하는 미사용 Import를 자동 제거하는 기능도 있습니다. 위와 같이 좌측 하단부에 '톱니바퀴 모양 아이콘'을 클릭한 후 'Optimize imp

Naver Blog

[우테코] 레벨2 5주차 회고록 - 지하철 미션 1단계 (Domain & Entity 불일치)

저번 주는 굉장히 정신이 없었기 때문에 회고를 지금 올리게 됐습니다. 장바구니 미션 다음으로는 '지하철 미션'을 진행했습니다. 미션을 한 마디로 소개하자면, 단순 CRUD는 아니었고 도메인 로직도 활용해야하는 미션이었습니다. 고민할 점이 많아서 굉장히 재밌었습니다. 이번 포스팅에서는 미션 1단계에서 무엇을 배웠고 어떤 피드백을 받았는지, 어떤 고민을 했는지 정리하도록 하겠습니다~ https://github.com/woowacourse/jwp-subway-path/pull/41 [1단계 - 지하철 정보 관리 기능] 제이(이재윤) 미션 제출합니다. by sosow0212 · Pull Request #41 · woowacourse/jwp-subway-path 에단 안녕하세요? 리뷰이 제이입니다~ 이번 미션은 굉장히 복잡했던 것 같습니다. 페어와 함께 Entity, Domain에 대해서 고민을 많이 했습니다. 그리고 복잡한만큼 Domain을 통해서 비즈니스 로직을 수행하고 Entity에 값

Naver Blog

[우테코] 레벨2 3주차 회고록 - 장바구니 웹 미션 1단계

3주차에는 장바구니 웹 미션 1단계를 진행 했습니다. 페어가 있는 주간이라 개별 공부는 많이 못했던 것 같습니다. 이번 미션에는 무엇을 배웠는지 적어보겠습니다! 1차 리뷰 정리 https://github.com/woowacourse/jwp-shopping-cart/pull/195 [1단계 - 상품 관리 기능] 제이(이재윤) 미션 제출합니다. by sosow0212 · Pull Request #195 · woowacourse/jwp-shopping-cart 시카, 안녕하세요! 제이입니다. 이번 미션을 구현하면서 다음과 같은 궁금즘이 있었습니다. 저는 상품을 수정 혹은 삭제를 할 때 id값을 기준으로 먼저 조회를 해서 null값인지 체크하고 예외를 발생시키고, 값이 있다면 수정 혹은 삭제의 과정을 진행합니다. 사실 update 혹은 delete 쿼리를 한 번만 날려도 될 것 같아서 바꿀 수는 있었지만, 그... github.com 질문1) 저는 상품을 수정 혹은 삭제를 할 때 id값을

Naver Blog

[Spring] HandlerMethodArgumentResolver를 이용해서 로그인 확인 로직 중복을 제거해보자 (Basic Auth를 이용한 예시)

안녕하세요. 오늘은 HandlerMethodArgumentResolver를 이용해서 로그인 중복 로직을 제거해보겠습니다. Basic Auth로 예시를 들었지만, 사실 많이 사용하시는 JWT에서도 적용이 가능하니 참고 부탁드리겠습니다 :) 문제 인식 우테코 미션을 진행하면서 로그인 관련된 요구사항이 추가되었습니다. Basic Auth를 이용해서, 유저가 요청을 할 때 로그인 정보를 확인하고 유효하다면 로직을 수행해야 했습니다. 저는 아래와 같은 방식으로 코드를 작성 했습니다. (미션 코드와는 관계가 없습니다!) @GetMapping @ResponseStatus(HttpStatus.OK) public Response findAll(@RequestHeader("Authorization") final String authHeaderValue) { // 1. 헤더에서 로그인 정보를 추출한 후에 로그인 정보가 DB에 있는지 확인한다. (없다면 예외!) MemberLoginRequestDto m

Naver Blog

스프링부트 커뮤니티 API 서버 만들기 #20 - HandlerMethodArgumentResolver 이용해서 중복 로그인 로직 제거 리팩토링

오랜만에 작성합니다! 오늘은 HandlerMethodArgumentResolver를 이용해서 기존 프로젝트의 로그인 중복 로직을 제거할 예정입니다. 요게 무엇인지 모르시는 분은 아래 글 참고 부탁드립니다 :) https://blog.naver.com/sosow0212/223092557576 [Spring] HandlerMethodArgumentResolver를 이용해서 로그인 확인 로직 중복을 제거해보자 (Basic Auth를 이용한 예시) 안녕하세요. 오늘은 HandlerMethodArgumentResolver를 이용해서 로그인 중복 로직을 제거해보겠습니다.... blog.naver.com 기존에 인증 로직은 JWT + Spring Security를 이용해서 진행 되었고 로그인의 순서는 헤더를 통해 Access Token이 들어오면, 이 토큰을 이용해서 컨트롤러에서 해당하는 Member를 찾아서 반환해주는 식으로 사용했습니다. 즉, 여러 컨트롤러에서 같은 로직(토큰 값으로 Memb

Naver Blog

[Spring] 계층형 아키텍처 (Layered Architecture)에 대해서 알아보자

오늘은 계층형 아키텍처란 무엇인지 알아보겠습니다. 먼저, 계층형 아키텍처는 Layered Architecture 라고도 합니다. 계층형 아키텍처라는 개념은 소프트웨어 설계 패턴 중 하나입니다. 시스템의 구성 요소를 여러 개의 계층으로 분리하여 각 계층이 특정 역할을 수행하도록 하는 패턴입니다. 이를 통해서 시스템의 유지보수성과 확장성을 향상시킬 수 있습니다. 즉, 역할을 나눠 각자의 역할에 충실하게 하면서, 재사용성 및 유지보수성을 높이기 위해 사용된다고 보시면 됩니다. 계층형 아키텍처는크게 세 가지로 나뉩니다. Presentation Layer Business Logic Layer Data Access Layer Presentation Layer 먼저 Presentation Layer는 사용자와 시스템 사이의 상호 작용 처리 계층의 역할을 합니다. 즉, 사용자의 요청을 받아서 처리한 후 응답을 다시 반환해주는 역할을 합니다. 스프링에서는 Controller의 역할이 이에 속합니다.

Naver Blog

[Spring] 스프링에서의 테스트에 대한 '나의 생각' (통합, 단위, 테스트 더블)

해당 게시글은, '저의 생각'일 뿐이니 피드백이나 틀린 부분은 댓글 부탁드리겠습니다 :) 목차 서론 문제 인식 결론 서론 우테코 Level2가 시작되면서 스프링을 배우기 시작했습니다. 미션을 진행하면서 당연히 테스트 코드를 작성했지만, 리뷰어님으로부터 다음과 같은 피드백이 왔습니다. 통합 테스트를 작성해보시는 것은 어떠실까요? 제이 테스트의 신뢰성이 보장될까요? 리뷰어님 처음에는 "이게 무슨 말일까?"라는 생각과 함께 곰곰히 생각해봤습니다. 우테코 오기 전에도 스프링을 통해 무엇을 개발할 때, 항상 테스트를 작성했지만 이에 대해 신뢰성을 생각해본적이 없었습니다. 왜냐하면 테스트란 성공하면 검증 되었다고 생각했기 때문입니다. (메서드 호출 후 결과가 동일하니!) 그리고 지금까지는 Bean을 띄워서 테스트를 하면 느리기 때문에, Mock 객체와 함께 테스트하고자 하는 메서드의 의존적인 것들은 스터빙을 통해 모두 의도된 값으로 나오게 했고, 그 때의 결과만 테스트했습니다. (각자의 레이어

Naver Blog

[우테코 생활기] 웰컴 키트 언박싱, 향로님 실물 영접

우테코에 들어온지 약 2달만에 웰컴 키트를 받았습니다. 어떤 굿즈가 있을지 엄청 기대기대 했습니다. 구성품은 텀블러, 노트, 포스트잇, 이상한 레고 이렇게 굿즈들이 있었습니다. 그리고 정말 예전부터 엄청 팬이었던 향로님이 우테코에 강연하러 오셨습니다! 향로님을 간단하게 소개하자면, jojoldu라는 이름으로 '기억보단 기록을'이라는 블로그를 운영하고 계십니다. (기술 블로그에서 거의 구글 독점) 그리고 '개발바닥'이라는 유튜브에서 향로라는 이름으로 활동하고 계십니다. jojoldu에 대한 tmi를 하자면, 'jojo(삼국지 조조) + ldu(이동욱)'이 의미인 걸 아시나요?? 이정도로 저는 엄청난 팬이랍니다 ㅋㅋㅋㅋ 실물로 보니 생각보다 키가 엄청 크셔서 놀랐습니다. 하여튼 너무 기념하고 싶어서, 노트북에 싸인을 요청했습니다. 이제 저 노트북에 포비, 김영한님 싸인만 있으면 될 것 같습니다~~

Naver Blog

[우테코] 레벨2 2주차 회고록 - 자동차 경주 웹 미션 2차 피드백, 테스트에 대한 고찰, 공부한 것들

이번 주에는 정말 엄청 많은 것들을 배우고 고민하는 시간이 많았습니다. 기존에 스프링을 사용하면서 '문제 해결'에만 초점을 맞춰서 구조나 원리를 하나도 몰랐기 때문에, 이번에는 내부와 동작 원리를 많이 파악하면서 공부하고자 했습니다. 그래서 2주차에는 이런 개념적인 부분에 대해 공부를 많이 했습니다. 웹 자동차 경주 2차 피드백과 함께 무엇을 배웠는지 확인해보겠습니다! 웹 자동차 경주 2차 피드백 PR 링크 https://github.com/woowacourse/jwp-racingcar/pull/103 [2단계 - 웹 자동차 경주] 제이(이재윤) 미션 제출합니다. by sosow0212 · Pull Request #103 · woowacourse/jwp-racingcar 터틀, 안녕하세요! 이번 미션을 구현하면서, Service와 DAO 레이어의 역할을 분리할 수 있도록 노력했습니다. Service 레이어는 비즈니스 로직을 처리할 수 있는 것의 초점을 맞췄고, DAO 레이어는 조회,

Naver Blog

[Spring] @Mock과 @MockBean의 차이점은 무엇일까?

혹시 글에 오류가 있으면 댓글로 피드백 부탁드립니다. 감사합니다 :) 안녕하세요. 이번에 우테코 미션을 진행하면서, 컨트롤러 테스트를 했는데 다음과 같은 피드백을 받았습니다. @WebMvcTest를 사용해서 컨트롤러 테스트를 하는 것은 어떻고, 이것의 편한 점은 무엇인가요? from. 리뷰어님 @ExtendWith(MockitoExtension.class) public class RacingGameWebControllerTest2 { @InjectMocks RacingGameWebController racingGameWebController; @Mock RacingCarService racingCarService; MockMvc mockMvc; ObjectMapper objectMapper = new ObjectMapper(); @BeforeEach void beforeEach() { mockMvc = MockMvcBuilders.standaloneSetup(racingGameWeb

Naver Blog

[Spring] @RequestBody를 사용할 때, 기본 생성자를 사용하는 이유에 대해 알아보자

문제 인식 최근에 우테코에서 미션을 진행하면서, 아래와 같은 POST 요청을 처리할 때 오류가 발생 했습니다. 먼저 오류가 발생한 요청에 대한 컨트롤러 코드는 다음과 같습니다. @PostMapping("/plays") public ResponseEntity<GameResultResponseDto> startGame(@RequestBody final StartGameRequestDto request) { Cars cars = makeCars(request.getNames()); TryCount tryCount = makeTryCount(request.getCount()); return new ResponseEntity<>(racingCarService.startRace(cars, tryCount), HttpStatus.OK); } StartGameRequestDto는 다음과 같습니다. public class StartGameRequestDto { private String names;

Naver Blog

[Spring] 스프링에서 ControllerAdvice와 ExceptionHandler를 사용해서 어떻게 예외처리를 할 수 있을까?

목차 개요 @ExceptionHandler 알아보기 @ControllerAdvice 알아보기 실제로 예외처리를 어떻게 하는지 알아보기 서버에서 예외가 발생한다면 어떻게 전송이 될까요? throw new IllegalArgumentException(); 일반적으로 스프링에서 별 다른 과정을 거치지 않고 위에 코드처럼 예외를 던지면 다음 사진과 같이 응답이 떨어집니다. 위에서의 예시처럼 흔히 던지는 예외를 프론트엔드 서버에서는 위와 같이 알기 어렵게 응답을 받습니다. 사진을 딱 봤을 때 무슨 에러인지 알 수 있을까요? 저는 500, 즉 "서버 에러가 발생했구나!"라고 밖에 생각을 안할 것 같습니다. 500에러인데, 어느 부분에서 에러가 발생했는지 체킹해서 메시지와 같이 보내준다면 좋지 않을까요? 혹은 위에 사진처럼 이미 정해진 데이터 형식으로 주는 것이 아닌, 프론트 서버와 응답 형식을 맞췄다면 그 형식에 맞춰서 주는게 프론트엔드 개발자 입장에서도 편하지 않을까요? 오늘은 이에 대해서

Naver Blog

[Spring] Dispatcher servlet은 무엇일까?

스프링 프레임워크를 공부하다 보면 'Dispatcher Servlet'이라는 것을 접하게 됩니다. 오늘은 스프링의 동작 순서와 함께 Dispatcher Servlet에 대해 알아보겠습니다. Dispatcher Servlet이란? Spring 프레임워크에서 웹 애플리케이션의 요청을 처리하는 핵심 컴포넌트 중 하나라고 보시면 됩니다. 웹 애플리케이션에서 클라이언트의 요청을 받으면, 이 Dispatcher Servlet이 일을 하게 됩니다. (개념적으로 프론트 컨트롤러라고 볼 수 있습니다.) Dispatcher Servlet과 함께 서브 컴포넌트(Handler Mapping & Adapter, View Resolver..)들이 역할을 함께 수행하면서 사용자의 요청을 처리합니다. 무슨 일을 하는지 간단하게 요약 느낌으로 설명하자면 다음과 같습니다. 1. Handler Mapping이 요청을 처리할 컨트롤러를 찾습니다. 2. Handler Adapter가 1번에서 찾은 컨트롤러를 실행합니다.

Naver Blog

[우테코] 레벨2 1주차 회고록 - 스프링 시작, 자동차 경주 웹 미션 1차 피드백

우테코 레벨2가 시작되고 첫 주가 지났습니다. 이번 주 미션은, 레벨1 기간 때 했던 '자동차 경주 미션'을 기반으로 스프링 프레임워크를 이용해서 웹 API를 만드는 것이었습니다. 원래 스프링을 공부했기 때문에 API로 바꾸는 것은 어렵지 않았습니다. 다만, 기존에는 Lombok을 남발했고, 생성자 주입과 같은 중요한 개념을 잘 몰랐고, 정말 내가 올바르게 스프링 프레임워크를 사용하는지 의문이 있었습니다. 그래서 이번 미션에서의 목표는, 스프링 코어 학습과 기존에 알던 방식으로 미션을 진행하고 받은 리뷰를 기반으로 방향을 잡는 것이었습니다. 지금 가장 크게 신경 쓰는 것은, 각 어노테이션의 작동 원리와 개념적인 부분입니다. 기존에는 "그냥 쓰니깐 쓰지"라는 생각이 강했고, 개념에 대해서는 무지했습니다. 이런 빈 부분을 채워서 더욱 성장하는게 이번 미션의 목표입니다. 웹 자동차 경주 미션 1차 피드백 PR 링크 https://github.com/woowacourse/jwp-racing

Naver Blog

객체지향의 사실과 오해를 읽고나서

안녕하세요. 최근에 토끼책이라고 많이들 부르시는 '객체지향의 사실과 오해'를 읽었습니다. 객체 지향을 공부하는 입장에서 이 책 추천을 많이 받기도 하고 책의 내용이 좋아서 3번을 읽었습니다. 사실 책과 거리가 멀고, 개발 공부도 "구글링으로 충분하지"라는 생각으로 책을 잘 읽지 않았습니다. 확실한 건 구글링으로 얻은 얕은 정보들을 책이 채워주고 본질적인 것에 대해 조금이나마 더 가까워졌다는 것이 느껴집니다. 이 책은 어느정도 객체 지향에 대해 공부를 해본 사람 혹은 하고있는 사람들이 읽는다면 책에서 설명하는 내용이 무엇인지 쉽게 연결할 수 있을 것이라고 생각합니다. 저도 실제로 미션도 진행하면서 책을 볼 때마다 매번 새로운 것을 배웠을만큼 지식의 깊이가 올라가는 것이 느껴졌기 때문입니다. 일반적인 전공 수업을 통해 객체 지향을 우리가 학습하고, "객체 지향이란 무엇인가?"에 대해서 답을 한다면 저는 다음과 같이 대답 했을 것 같습니다. "현실 세계와 동일한 객체를 만들고, 원하는 것

Naver Blog

[Java] 진짜 누구나 이해 가능한 '정적 팩토리 메서드'에 대해 알아보자

안녕하세요. 오늘은 정적 팩토리 메서드(Static Factory Method)에 대해서 알아보겠습니다. 정적 팩토리 메서드란 무엇인가요? 아마도 이 패턴을 처음 보시는 분들은 '정적 팩토리 메서드(Static Factory Method)'라는 이름만 보고 무엇인지 감이 쉽게 오지 않으실 것 같습니다. 이는 GoF 디자인 패턴 중 팩토리 패턴에서 나온 용어로 정의한 것으로 객체를생성해주는 메서드로 볼 수 있습니다. 일반적으로 우리는 객체를 생성할 때 생성자를 사용합니다. 그렇다면, 위에서 "객체를 생성해주는 메서드"라는 말을 보면 생성자가 아닌, "어떤 메서드가 객체를 생성해주는구나"로 얼추 이해해볼 수 있겠습니다! 이 설명을 보고나서 우리는 여기서 몇 가지 의문점이 생깁니다. 생성자를 쓰면 되지 왜 굳이 정적 팩토리 메서드를 쓰는가? 예시로 설명을 보고 싶은데.. 이 의문점들을 이번 포스팅으로 천천히 풀어나가보겠습니다. 생성자 대신 정적 팩토리 메서드를 쓰는 이유는 무엇인가요? 이

Naver Blog

[Spring] 의존성 주입(DI)과 주입 방식에 대해 알아보자

안녕하세요. 오늘은 스프링에서 DI(Dependency Injection)이라고 부르는 의존성 주입에 대해 알아볼 예정입니다. 의존성 주입이란? 의존성 주입은 DI(Dependency Injection)이라고도 불립니다. 스프링 프레임워크에서, 의존성 주입은 직접 객체를 생성하거나 참조하지 않고 외부에서 주입받는 것을 의미합니다. 이는 객체의 의존 관계를 개발자가 직접 코드로 작성하지 않아도 되고, 코드의 유연성과 재사용성을 높일 수 있습니다. 즉 정리하자면, 객체 간의 의존 관계를 느슨하게 만들기 위한 것이라고 보면 됩니다! 의존성을 주입하는 방법은 여러가지가 있는데, 같이 알아보겠습니다. 다양한 의존성을 주입하는 방법 생성자 주입 생성자 주입은 말 그대로 생성자를 통해서 의존성을 주입하는 방식입니다. 생성자라는 특징으로 인해 호출 시점에 자동으로 의존성을 주입하게 됩니다. 생성자 주입은 스프링에서 가장 권장되는 방식입니다. 왜냐하면 먼저 객체 생성 시점에 모든 의존성이 주입되기

Naver Blog

[Spring] IoC(Inversion Of Control) 컨테이너와 스프링 빈(Bean)에 대해 알아보자

스프링을 사용하다보면 'IoC 컨테이너'라는 용어와 'Bean'이라는 용어를 자주 접하게 됩니다. 오늘은 이에 대해서 알아보도록 하겠습니다. IoC (Inversion Of Control), Bean 흐름 설명 IoC는 흔히들 '제어의 역전' 이라고 부릅니다. 말은 조금 어렵지만 풀어서 설명하자면, 외부에서 객체의 생성 및 생명 주기 등등을 책임져서 기존 개발자가 가졌던 모든 객체에 대한 제어권이 바뀌었음을 의미합니다. 이를 통해서 개발자는 코드를 작성할 때 객체 간의 의존성을 최소화하고 유연성과 확장성을 높일 수 있습니다. 일반적으로 객체끼리의 의존성은 코드 내에서 직접 생성하고, 객체의 메서드를 호출하여 처리하기도 합니다. 하지만 IoC에서는 객체를 직접 생성 및 호출하는 방식이 아닌, 외부에서 객체를 생성 혹은 호출합니다. 이를 통해 개발자는 로직에 집중하고, IoC에서는 인스턴스를 관리해주기 때문에 객체끼리의 결합도를 낮추고 유지 보수성 및 재사용성을 높일 수 있습니다. Sp

Naver Blog

[개발 일기 #28] 3월의 개발 공부 : 성장과 도움주기

저도 드디어 백준 플레티넘 등급을 달았습니다. 사실 dfs 양치기를 하니 등급은 올라가는데 정말 플레5 실력이냐라고 물으면 그건 아닌 것 같습니다...ㅠㅠ 하여튼 작년부터 목표로 했는데 성취를 해서 기분이 너무 좋습니다! 성장 이번 3월 달에는 많은 것을 배웠습니다. 먼저 우테코에서 블랙잭과 체스 미션을 통해서 다양한 개발 기법에 대해 익힐 수 있었습니다. (자세한 내용은 우아한테크코스 카테고리 글 확인해주세요!) 기존에는 스프링 프레임워크만 잘 쓰면 장땡이라고 생각을 했는데, 확실히 자바에 대한 기본기를 많이 다듬다보니 스프링에서 당연스럽게 생각하고 쓰던 것들에 대해서 기술적 근거를 가지고 사용할 수 있게 됐습니다. 특히 정적 팩토리 메서드와 Stream, Lambda, 함수형 인터페이스에 대해서 그냥 쓰는 것이 아니라 왜 쓰는지에 대해 공부를 했다보니 응용도 하기 좋았습니다. 이제 우아한테크코스 Level 1이 끝나가는데, Level 2로 넘어가기 전에 아직 다 못 읽은 개발 서

Naver Blog

[우테코] 레벨 1을 마무리 하면서

우테코에 들어온 지 벌써 약 두 달이 지났습니다. 레벨 1 교육도 무사히 마쳤습니다. 매일매일 코딩에 몰두하고, 크루들과 함께 토론을 하면서 시간이 정말 빠르게 갔다고 느껴집니다. 예전에는 보이지 않았던 것들이 보이고, 이제서라도 자바 기본기를 조금 더 단단히 쌓은 것 같습니다. 우테코에서 학습하면서 좋았던 점은 편견 없이 서로를 들어주고 배려해주는 분위기가 형성된다는 점입니다. 또한 학습 면에서도 서로 배운 것을 공유하면서 토론을 하는데, 이전에 알지 못했던 부분도 많이 알게 되었고, 어떤 기술을 사용할 때 그 기술의 장단점 및 다른 방법은 없는지에 대해서도 파악할 수 있게 되었습니다. 이번 레벨 1에서 기억이 가장 크게 남았던 것은 테코톡 발표였습니다. 백엔드 크루 중에서 테코톡 첫 발표라서 엄청 떨렸습니다. 그래도 온보딩 팀원들이 잘 도와줘서 뭐 어찌저찌 잘 마무리한 것 같습니다. 이 부분에 대해서는 추후에 글 올리도록 하겠습니다! 이번 기간에 아쉬운 점도 있었습니다. 레벨 1

Naver Blog

스프링부트 커뮤니티 API 서버 만들기 #19 - 프로젝트 클린코드 리팩토링, 예외 테스트 작성하기

스프링부트 커뮤니티 API 서버 만들기 #19 - 프로젝트 클린코드 리팩토링, 예외 테스트 작성하기 피드백 및 질문은 댓글로 남겨주세요 :) 작업한 내용은 깃허브에서 확인하실 수 있습니다. https://github.com/sosow0212/community GitHub - sosow0212/community: Community API Server (Main project) Community API Server (Main project). Contribute to sosow0212/community development by creating an account on GitHub. github.com 안녕하세요? 오랜만에 Community 프로젝트 포스팅을 쓰는 것 같습니다. 우테코 활동을 잠시 쉬는 겸해서 지금까지 배운 것들을 바탕으로 리팩토링 작업을 진행했습니다. 예전에 이 프로젝트를 바탕으로 많이 배웠고, 덕분에 가장 애정하는 프로젝트인만큼 오래 살펴보고 리팩토링 작업을 진행했습

Naver Blog

[개발 일기 #27] 2월의 개발 공부와 새로운 목표

드디어 백준 600문제를 풀었습니다 노력파 골드1인데, 이번년도 목표는 정말 알고리즘에 통달하는 것입니다! 과연 가능할까요? 알고리즘은 풀 수록 기본 개념을 더욱 자세하게 알아야할 것 같습니다. 항상 지금까지 다익스트라는 뭔가 보기가 싫어서 잘 풀지를 않았습니다. 하지만, 앞으로 코테를 위해서는 이제 더 이상은 피할 수가 없을 것 같아요.. 돌아오는 3월말까지 목표는 다익스트라 알고리즘을 어느정도 마스터하는 걸 목표로 세웠습니다. 백준으로 어느정도 문제에 더 익숙해지고 기존에 목표한 프로그래머스를 모두 풀어야겠습니다! 최근에 공부하는 환경이 많이 바뀌었습니다. 기존에 혼자 독학했던 방식보다 여러명과 다같이 토론도 하면서 함께 배우는 과정에서 이번 달은 정말 많이 성장한 것 같습니다. 정말 기본적인 개발 패턴도 배웠고, 객체지향적으로 설계하는 방법에 대해 많이 배웠습니다. 아마도 독학으로 공부를 계속 했다면, 이런 부분은 별로 중요하지 않다고 넘겼을 생각에 아찔합니다. 또한 지금까지는

Naver Blog

[좋은 코드, 나쁜 코드] 1차 스터디, 같이 얘기할 것들 정리

범위 ~Chapter 3 책을 읽으면서 작성한 포스팅이라 문맥이 어색할 수도 있습니다. Chapter 1 : 코드 품질 Q. 책의 저자가 제시한 네 가지 상위 수준 목표 중 "코드는 변경된 요구 사항에 적응할 수 있어야 한다.", "중복 코드는 피해야한다." 등등 (10p) 와 같은 내용들은 결국 '객체 지향'을 지키며 개발하자는 뜻 같다. 다른 사람들의 뜻은 어떤가? 1장을 읽으면서, 코드에 주관을 개입시키지 말고 정말 객관적인 코드를 작성하라는 뜻 같았다. Q. (21p) 테스트하기 용이한 코드를 만드는 것에 대해선 동의한다. 하지만 너무 테스트만을 생각하고 만들라는 뜻 같다. 회사의 재정과 시간에 따라서 테스트 작성을 꼼꼼하게 못할 수도 있다. 이거는 전략 차이라고 생각한다. 아무리 이런 상황이라도, 책의 저자처럼 반드시 테스트하기 좋은 코드를 만들어야 할까? (만약 회사에 재정이 안 좋은데, 테스트하기 좋은 코드를 만들기 위해 돌아가는 쓰레기 코드여도 시간을 들여서라도 꼭 테

Naver Blog

[자바] 백준 15559 : '내 선물을 받아줘' 박살내보기 / DFS / 유사 문제 추천

https://www.acmicpc.net/problem/15559 15559번: 내 선물을 받아줘 15559번 제출 맞힌 사람 숏코딩 재채점 결과 채점 현황 질문 게시판 내 선물을 받아줘 시간 제한 메모리 제한 제출 정답 맞힌 사람 정답 비율 2 초 512 MB 1437 589 439 40.055% 문제 욱제는 구사과의 열렬한 팬이다. 오늘 욱제는 구사과에게 선물( )을 전달해주려고 한다. 지난 며칠간의 관찰 끝에 욱제는 구사과의 이동 패턴을 모두 파악했다. 구사과가 있는 곳은 N×M 크기의 직사각형 지도로 나타낼 수 있으며, 1×1크기의 정사각형으로 나누어져 있다. 구사과의 위치는 (i, j)로 나타낼 수 있으며, (i, j)... www.acmicpc.net 오늘 박살 예정인 '내 선물을 받아줘' 문제는 골드2 난이도, 40% 정답률에 DFS 유형 문제입니다. 문제 분석 및 풀이 문제에서 요구하는 것은 다음과 같습니다. N, S, W, E 좌표가 맵에 표시됩니다. 맵에서 해당하

Naver Blog

[Java] 겉은 어렵지만 속은 쉬운 '제네릭' 알아보자!

제네릭(Generics), 저는 이걸 자바의 정석에서 처음 접했습니다. 이름은 뭔가 딱딱하고 재미없어 보이지만 알고보면 쉬운 제네릭, 같이 알아보겠습니다! 제네릭은 무엇인가요? "자바에서 데이터의 타입을 일반화한다." 라는 것을 의미합니다. 즉 데이터의 타입을 클래스 내부에서 지정하는 것이 아니라, 외부에서 사용자가 지정하는 것을 의미합니다. 외국어인가요? 어렵습니다. 맞습니다! 제네릭의 개념만 본다면, 어렵고 와닿지가 않을 수 있습니다. 따라서 다음 예시를 통해 제네릭을 쉽게 배워보겠습니다~ 저는 어떤 타입이 들어와도 다 저장할 수 있는 리스트를 만들고 싶습니다. 요구사항을 들어주기 위해서, 이 리스트의 이름을 'JayList'로 두고 다음과 같이 '제네릭'을 사용해서 만들었습니다. public class JayList<Type> { Type element; void setElement(Type element) { this.element = element; } Type getEle

Naver Blog

[우테코] 4주차 회고 : 배운 점과 스터디

4주차 회고록 이번 4주차에는 사다리 미션이 2차까지 빠르게 끝나게 돼서 시간이 많았습니다. 그래서 개인 공부 시간이 많았던 것 같습니다. 배운 것 Generics 공부 사실 제네릭을 지금까지 스프링을 하면서 많이 사용했는데, 정확한 원리도 잘 몰랐고 “그냥 쓰니깐 쓰지!” 이런 느낌으로 사용했습니다. 어떤 기술이든 사용하는 이유와 원리가 중요하다고 생각하는데, 언행불일치의 끝판왕급으로 지금까지 제네릭을 깊게 공부해보지 않았다는 생각을 반성하면서 블로그 포스팅까지 했습니다. 제네릭 공부를 덤으로 이번 미니 미션도 잘 구현할 수 있었습니다! VO 공부 및 Equals, Hash 재정의 공부 저문과 같이 회고를 하면서 저문에게 VO를 사용할 때 재정의를 하면 좋다는 점에 대해 알게 되었습니다. 재정의를 하면서 물리적인 값을 쉽게 비교할 수 있다는 점이 큰 장점 같습니다. [객체지향의 사실과 오해], [좋은 코드, 나쁜 코드] 책 읽기 책을 정말 살면서 거의 읽지 않아서 처음에는 책 읽는

Naver Blog

[Java] 두유 노 '상속'?

자바 개발을 하다보면, 상속과 조합이라는 키워드를 보게 되고 개념만 알다가 적용하는 시점이 다가옵니다. 적용하기 직전에 개념을 먼저 확실하게 확립하고 적용한다면, 어떤 시점에서 상속 혹은 조합을 쓸 수 있는지에 대해서와 이를 통해 얻는 장단점을 확실히 알고 개발할 수 있습니다. 오늘은 상속이 무엇인지 알아보겠습니다. 후편으로는 조합, 그리고 상속과 조합에 대해 비교하는 글을 작성하겠습니다. 상속(Inheritance)이란? 상속은 우리가 현실 세계에서 자주 쓰는 그 용어와 동일합니다. 먼저 상속을 해주는 클래스는 [부모 클래스] 상속 받는 클래스를 [자식 클래스, 하위 & 서브 클래스]라고 합니다. 부모 클래스를 상속 받으면 자식 클래스는 부모 클래스의 코드를 사용할 수 있게됩니다. 그렇다면 상속의 장점은 무엇일까요? 상속의 장점 부모 클래스의 코드를 받기에 중복 코드를 줄일 수 있다. 유지 보수하기 좋다. (부모 클래스만 바꾸면 자식 클래스는 모두 바뀌기 때문!) 다형성을 구현할

Naver Blog

[우테코] 5주차 회고록 - 블랙잭 미션 배운 점과 이번 주 생활에 대해서

우테코에 들어온 지 얼마 안 된 것 같은데, 정말 빠르게 시간이 흘러갔습니다. 매주 배우는 것과, 크루들과의 자율적인 학습 및 토론으로 하루하루 정말 많은 성장을 하고 있음을 느끼고 있습니다. 이번 주에는 블랙잭 미션을 진행했습니다. 블랙잭 미션을 처음 접했을 땐 뭔가 쉽다고 생각했지만, 결코 쉽지가 않았습니다. 이런 과정에서 제가 무엇을 배웠고 느꼈는지 적어보도록 하겠습니다. 블랙잭 미션을 통해서 배운 점 및 느낀 점 flatMap을 통해서 stream()에서 stream()을 돌릴 수 있다. 기존에 블랙잭에서 카드를 생성하는 과정에서 어쩔 수 없이 2중 for 문을 사용했지만, flatMap()을 통해서 인덴트를 줄일 수 있었습니다. 2중 for 문을 사용하는 로직은 알고리즘을 풀 때도 많이 사용하고, 미션 및 프로젝트 할 때도 정말 많이 사용했는데 지금이라도 flatMap()에 대해 알게 돼서 앞으로 자주 사용할 것 같습니다. 이번 미션에서 카드를 뽑는 행위를 card.remo

Naver Blog

[우테코] 6주차 회고록 - 체스 1,2단계 미션을 진행하고 나서 배운 점

이번 주는 체스 미션을 시작했습니다. 진행하고 나서 느낀 점은, 역시 악명 높은 체스 미션이었습니다..! 페어인 아코랑 1,2 단계를 너무 재밌게 진행했습니다. 체스 미션에서 개인적으로 어려웠던 점은 다음과 같습니다. 기물들의 기본적인 움직임 구현 폰의 움직임 포인트와 공격 포인트 분리 Position Enum의 사용이 모호함 (굳이 안 써도 되는 객체인가 고민을 많이 했습니다.) 이번 단계는 운이 좋게 빠르게 Merge가 되어서 리뷰 받은 내용과 질문을 빠르게 정리해보겠습니다. PR 링크 https://github.com/woowacourse/java-chess/pull/439 [1, 2단계 - 체스] 제이(이재윤) 미션 제출합니다. by sosow0212 · Pull Request #439 · woowacourse/java-chess 카프카, 안녕하세요! 제이입니다. 미션을 진행하면서 처음에 체스 말에서 Position을 가지게 했습니다. 아코와 함께 고민한 끝에 Position

Naver Blog

[우테코] 7주차 회고록 - 체스 3,4단계 미션을 마무리하고 배운 점

이번에 체스 미션 3,4 단계가 빠르게 Merge가 되었습니다. 이렇게 Level 1의 마지막 미션이 잘 마무리가 되었습니다. 체스 미션은 생각할 것들이 많아서 정말 재밌는 미션이었고, 리뷰어인 카프카의 피드백으로 정말 많이 성장했다는 것을 느꼈습니다. 오늘은 제가 체스 미션을 진행하면서 무엇을 배웠는지 적어보도록 하겠습니다. PR 링크 https://github.com/woowacourse/java-chess/pull/530 [3, 4단계 - 체스] 제이(이재윤) 미션 제출합니다. by sosow0212 · Pull Request #530 · woowacourse/java-chess 카프카, 안녕하세요! 주말은 잘 보내셨나요? 이번 3, 4단계 미션은 어려웠지만, 정말 배운 것도 많았고 재밌게 진행 했습니다. 특히 "JPA가 정말 편한 기술이었구나"를 많이 느꼈습니다.. 미션의 단계가 높아질 수록, 컨트롤러가 많이 복잡해졌습니다. 가독성과 확장성을 고려했을 때 컨트롤러 부분에 커맨

Naver Blog

[Java] DTO에 대해 알아보자

주관이 들어간 글입니다! 피드백은 댓글로 부탁드립니다. 안녕하세요. 오늘은 DTO에 대해 알아보겠습니다. 알아보기 전에 먼저 DTO란 무엇일까요? Data Transfer Object의 약자로 계층 간 데이터 교환을 위한 사용되는 객체입니다. 오늘 글을 통해서 DTO를 사용하는 이유와 사용하면 좋은 점에 대해 작성해 보겠습니다. DTO를 만드는 이유 앞서 설명했듯이 DTO는 계층 간 데이터 교환을 위해 사용되는 계층입니다. 앞서 설명한 DTO의 약자를 봤을 때, 저는 처음에 다음과 같은 생각이 들었습니다. "계층끼리 객체를 주면 될 텐데 왜 따로 DTO를 만들어서 주는 걸까?" 이에 대해 차근차근 설명해 보겠습니다. MVC 패턴을 사용하여 콘솔 프로그램을 만든다고 가정했을 때, 우리는 기존에 Controller에서 객체 자체를 View로 넘겨주었습니다. 그리고 View에서는 받은 객체로 출력에 필요한 행위를 작업했습니다. 먼저 DTO를 쓰지 않았을 때 여기에서 '생길 수 있는 문제점

Naver Blog

[Java] 만취한 사람도 쉽게 이해할 수 있는 '일급 컬렉션'에 대해 알아보자!

글에 오류가 있으면 댓글로 피드백 부탁드립니다 :) '일급 컬렉션' 뉘슈? 일급 컬렉션이란 먼저 다음과 같습니다. Collection을 포함한 클래스는 반드시 다른 멤버 변수가 없어야 한다. 부가설명 : Collection(List, Set ..)을 Wrapping한 변수가 있다면 그 외에 다른 멤버 변수는 없어야한다! --> 오마이갓.. 이게 무슨 말일까요? 먼저 예시를 통해 일급 컬렉션을 이용한 프로그램을 보면서 이것의 장점과 사용 이유에 대해 더 알아보겠습니다. 예시(일급 컬렉션 적용 ver.) 예시에 앞서 먼저 프로그램 요구사항은 다음과 같습니다. 엔델 : 제이, 자동차 경주 게임 프로그램을 만들어주세요! 1. 자동차 경주를 할 사람은 'odo', 'kokodak', 'jay' 로 고정해주세요. 2. 저는 평등한게 좋으니 모든 라운드마다 자동차의 거리는 똑같이 1씩 증가시켜주세요. 3. 라운드의 수는 5로 고정입니다. 예상 결과 ==> 게임이 종료되면, 3명의 자동차의 거리가

Naver Blog

[Java] 쉽다 쉬워! 단위 테스트에 대해 알아보자

오늘은 단위 테스트에 대해 알아보겠습니다. 단위 테스트란? 단위 테스트는 영어로 Unit Test입니다. 단위 테스트는 모듈 혹은 애플리케이션 안에 있는 개별적인 코드 단위가 의도한 대로 작동하는지 확인하는 행위입니다. "뭔 말인가요? 더 쉽게 설명해 주세요!" ==> 하나의 애플리케이션에는 한 개 이상의 작동하는 기능들로 구성되어 있습니다. 단위 테스트란, 이런 기능들을 '개별적으로' 테스트함을 의미합니다. "아~ 그러면 단위 테스트는, 기능들이 개별적으로 작동하는지 테스트하는 행위이군요." 맞습니다! 이렇게 생각하셨다면 단위 테스트의 뜻을 파악하신 것입니다 그렇다면 단위 테스트는 왜 사용할까요? 다음 예시를 통해 알아보겠습니다. 애니메이션을 바탕으로 프로그램 구현을 하는 '홍보와 졸부' 회사에 신입 개발자 제이가 들어왔습니다. 회사에 들어왔는데, 이오가 제이에게 새로운 프로그램 제작을 맡겼습니다. 이오 : [토끼와 거북이 경주 게임]을 다음과 같은 흐름으로 만들어주세요! 1. 토

Naver Blog

[Effective Java] 정적 팩터리 메서드, 빌더 패턴, 그 외

정적 팩터리 메서드 정적 팩터리 메서드란 무엇인가요? 쉽게 말해서 객체의 생성을 담당하는 클래스 메서드입니다. // 1. 기존 생성 방식 Car car = new Car("name"); // 2. 정적 팩터리 메서드 방식을 사용한다면 Car car = CarFactory.createCar("name"); 간단하게 위와 같은 느낌으로 정적 팩터리 메서드는 객체의 생성을 담당해 줍니다. 정적 팩터리 사용 전과 후 뭐가 달라졌을까? 차이점 및 장점과 단점을 알아보자. 삐링~ 요구사항이 들어왔습니다. 성하: Car 클래스 생성의 규칙은 다음과 같습니다. 1. Car 생성자에서 'name', 'distance' 필드를 받는 경우는 들어온 값으로 초기화해주세요. 2. Car 생성자에서 'name' 필드만 받는 경우는 '거리 필드'의 초기 값은 0으로 해주세요. 3. Car 생성자에서 'distance' 필드만 받는 경우는 이름은 "null"로 초기화해주세요. 정적 팩터리 메서드를 배우기 전에

Naver Blog

[우테코] 사다리 타기 TDD 미션, 독서 스터디 등등 2주 차 회고

정신없는 한 주가 또 흘렀습니다. 하루 종일 너무 정신없이 빨리 지나가지만 그래도 같은 분야에 있는 사람들과 함께 해서 너무 재밌는 하루하루를 보내고 있는 것 같습니다. 친구들이 잠은 죽어서 자라고 하는데, 저는 죽어있는 걸까요? 왜 이리 일어나기가 힘들까요..! 먼저 이번 주에 가장 큰 주제는 두 번째 미션인 '사다리 타기' 미션입니다. 미션이 점점 어려워지는 것을 실감하고 구조적 설계의 중요성을 많이 느끼게 된 것 같습니다. 먼저 같은 페어인 저문과 진행을 했습니다. 저문과 함께 미션을 하면서 느낀 점 제가 덤벙거리면서 놓치는 통일성을 저문이 모두 잡아줬습니다. 깃 커맨드는 덤으로..! 코딩 스타일이 다른 면이 있는데, "내가 맞는 것도 아니구나"를 많이 느꼈습니다. 다양한 코딩 스타일을 접한다는 점이 페어 프로그래밍의 최고 장점이라고 생각합니다. 각종 컨벤션을 배웠습니다. static, final 같은 것들의 순서가 있는지 처음 알았는데 지금이라도 고칠 수 있어서 다행입니다!

Naver Blog

[Java] 쏘 이지~ 원시값 포장에 대해 알아보자

현재 배우고 있는 입장으로, 포스팅 내용에서 틀린 부분이 있으면 댓글로 피드백 부탁드립니다c️ 원시값 포장이란? 원시값 포장이 무엇인가요? 원시 타입의 변수를 객체로 포장한 것입니다. 말이 조금 어려울 수 있는데, 다음 예시로 어떤 느낌인지 확인해보겠습니다. public class Member { private final String name; private final int age; public Member(final String name, final int age) { this.name = name; this.age = age; } public String getName() { return name; } public int getAge() { return age; } } 이런 클래스가 있다고 가정해보겠습니다. 여기서 원시값 포장을 진행하면 아래 코드와 같이 변경됩니다. public class Member { private final Name name; private final A

Naver Blog

[자바] 백준 1012 : 유기농 배추 / 그래프 + DFS 풀이

https://www.acmicpc.net/problem/1012 1012번: 유기농 배추 문제 차세대 영농인 한나는 강원도 고랭지에서 유기농 배추를 재배하기로 하였다. 농약을 쓰지 않고 배추를 재배하려면 배추를 해충으로부터 보호하는 것이 중요하기 때문에, 한나는 해충 방지에 효과적인 배추흰지렁이를 구입하기로 결심한다. 이 지렁이는 배추근처에 서식하며 해충을 잡아 먹음으로써 배추를 보호한다. 특히, 어떤 배추에 배추흰지렁이가 한 마리라도 살고 있으면 이 지렁이는 인접한 다른 배추로 이동할 수 있어, 그 배추들 역시 해충으로부터 보호받을 수 있다. 한 배추의 상하좌우 네 방향에 다른 배추가 위치한 경우에 서로 인접해있는 것... www.acmicpc.net 실버2 난이도의 정답률 38% 문제입니다. 그래프 + DFS(혹은 BFS) 알고리즘으로 해결할 수 있습니다. 문제 분석 및 풀이 문제는 간단합니다. 배추밭의 가로와 세로 길이가 주어집니다. 그리고, 배추가 심어진 위치가 주어집니다.

Naver Blog

[Java] AssertJ 문법과 간단한 예시 (예외처리 검증 추가)

안녕하세요. 오늘은 자바에서 테스트를 할 때 많이 사용되는 AssertJ와 이를 통해 단위테스트를 진행해보고자 합니다. AssertJ AssertJ는 assertion을 제공하는 자바 라이브러리로 에러 메시지와 테스트 코드의 가독성을 높여주는 라이브러리입니다. 쉽게 말해서 테스트의 흐름을 작성할 수 있는 라이브러리라고 보시면됩니다! 메서드 체이닝을 통해서 직관적으로 읽힙니다. 예제를 보면서 설명을 진행하겠습니다. @Test void stringDoubleSplitTest() { //given String input = "1,2"; //when final String[] splitedInput = input.split(","); //then assertThat(splitedInput).containsExactly("1", "2"); } 위에 예시를 보면 input을 split한 것을 검증하는 코드입니다. AssertJ는 위에서 메서드 체이닝으로 직관적이라고 말씀 드렸죠? // then

Naver Blog

[우테코 5기] 1차 미션 자동차 경주 정리 및 회고록

약 일주일 동안 진행했던 미션이 끝이 났습니다. 페어 프로그래밍을 처음 해봤는데, 너무 재밌었고 배운점이 많았습니다. 같은 페어인 우르한테 인텔리제이 여러 단축키를 많이 배웠고, 같이 개발을 하면서 테스트와 여러가지 꿀팁들을 많이 얻었습니다. 강의를 들으면서 느낀 점과 궁금한 점 Q) System.out.println()을 냅두고 테스트 코드를 작성하는 이유는? 기능이 커지면 sout으로는 오래 걸린다. 또한 서버도 껐다 켜야한다 등등 반면, 테스트 코드를 작성하면 이러한 단점을 모두 커버할 수 있다. (단지, 테스트 작성 시에만 시간이 듬) 테스트 코드를 사용하면 프로덕션 코드의 정확성을 판단할 수 있다. 리팩토링 시에도! 프로덕션 코드가 잘못 됐을 때를 대비해서 테스트의 수를 늘릴 수도 있다. 프로덕션 코드의 예외 상황을 생각해서 테스트의 수를 늘린다. 이건 기준을 잘 잡고 어디까지 테스트를 작성해야하는지를 고민해봐야한다. (불안하지 않을 정도로...) Q) 테스트 메서드의 실행

Naver Blog

[Java] final 키워드에 대해 알아보자

우테코에서 자동차 미션을 진행하면서, final 키워드를 제멋대로 사용해서 피드백을 많이 받았습니다. final 이란 지금까지 '바뀌지 않는'으로만 알고 있었는데, 오늘은 final 키워드에 대해 구체적으로 배워보고 언제 사용할지 알아보도록 하겠습니다! final : 의미와 역할을 알아봅시다! 재할당 불가를 명시합니다. 위에 사진과 같이 final로 선언을 한 age를 재할당 한다면 오류가 발생합니다. final 인자는 메서드 내에서 변경이 불가능합니다! 위와 같이 increaseNumber() 메서드의 인자를 final로 받아준다면, final로 넘어오는 number 변수는 읽기만 가능해집니다. final 키워드를 메서드 앞에 사용한다면, 오버라이드가 안됩니다. final 키워드를 클래스 앞에 사용한다면, 다른 클래스에서 상속할 수 없게 됩니다! final 키워드는 다양한 역할을 하네요! 그렇다면 언제 사용해야 할까요? 이를 대답하기 위한 여러가지의 관점이 있습니다. 각자의 관점에

Naver Blog

[자바] 백준 2589 : 보물섬 / BFS 풀이

https://www.acmicpc.net/problem/2589 2589번: 보물섬 문제 보물섬 지도를 발견한 후크 선장은 보물을 찾아나섰다. 보물섬 지도는 아래 그림과 같이 직사각형 모양이며 여러 칸으로 나뉘어져 있다. 각 칸은 육지(L)나 바다(W)로 표시되어 있다. 이 지도에서 이동은 상하좌우로 이웃한 육지로만 가능하며, 한 칸 이동하는데 한 시간이 걸린다. 보물은 서로 간에 최단 거리로 이동하는데 있어 가장 긴 시간이 걸리는 육지 두 곳에 나뉘어 묻혀있다. 육지를 나타내는 두 곳 사이를 최단 거리로 이동하려면 같은 곳을 두 번 이상 지나가거나, 멀리 돌아가서는 안 된다. 예를 들어 위와 같이 지도가 주어졌다... www.acmicpc.net 골드5 난이도, 정답률 37% 문제입니다. 개인적으로 잘 만든 BFS문제라고 생각이 듭니다. 문제 이해 및 분석 이 문제는 요구 사항을 이해하기 조금 어려웠습니다. 문제에서 보물이 묻힌 두 곳의 최단 거리를 구하라고 했는데, 일단 여기서

Naver Blog

과소비의 1월

이번 1월은 기억에 많는 일이 많았습니다. 나중에도 기억하고 싶어서 글을 써봅니다. 먼저 연초에는 누나들과, 매형과 신사역 앞에 김수사라는 일식집에서 모였습니다. 한국느낌의 일식집이었습니다. 큰누나가 한턱 크게 쏴서 엄청 맛있게 먹고왔습니다. 울 큰누나 최고 ㅋㅋㅋㅋㅋ 누나들과 매형의 선물 누나들이 있으면 좋습니다 (시스터보이 아님) 드디어 선릉역 앞에서 자취를 하게 됐습니다. 집을 여러 곳 보다가 마지막으로 본 곳을 골랐습니다. 오늘의집 어플과 유튜브를 보면서 어떻게 꾸밀지 많이 찾아봤습니다. 원래는 타일카페트도 깔고 더 예쁘게 꾸미고 싶었는데 그건 좀 청소가 힘들 것 같아서 나중에 자가가 있다면 거기서 꾸미는 걸로.. 스마트 조명 쓰니깐 너무너무 아늑합니다 누나가 있으면 좋은 점2 갑자기 작은 누나랑 잼민이 시절 때 같이 게임을 하면서 사기 당해서 둘이 펑펑운게 생각나네요 ㅋㅋㅋㅋ 하여튼 이사 오면서 운동을 다시 시작했는데, 헬창인 매형과 작은 누나가 고민을 해서 고단백의 맛난

Naver Blog

[자바] 2023 카카오 블라인드 채용 : 택배 배달과 수거하기 풀이 (그리디)

https://school.programmers.co.kr/learn/courses/30/lessons/150369?language=java 코딩테스트 연습 - 택배 배달과 수거하기 당신은 일렬로 나열된 n 개의 집에 택배를 배달하려 합니다. 배달할 물건은 모두 크기가 같은 재활용 택배 상자에 담아 배달하며, 배달을 다니면서 빈 재활용 택배 상자들을 수거하려 합니다. 배달할 택배들은 모두 재활용 택배 상자에 담겨서 물류창고에 보관되어 있고, i 번째 집은 물류창고에서 거리 i 만큼 떨어져 있습니다. 또한 i 번째 집은 j 번째 집과 거리 j - i 만큼 떨어져 있습니다. (1 ≤ i ≤ j ≤ n ) 트럭에는 재활용 택배 상자를 최대 cap 개 실을 수 있습니다. 트럭은 배달할 재활용 택배 상자들을 실어 물류창... school.programmers.co.kr Level2, 782 solve 정답률 22% 그리디 문제입니다. 개인적으로 시간이 많이 들었고 그리디한 방법을 찾기 어려운

Naver Blog

[자바] 백준 1937 : 욕심쟁이 판다 / DFS + DP 풀이 / 유사 문제

https://www.acmicpc.net/problem/1937 1937번: 욕심쟁이 판다 1937번 제출 맞힌 사람 숏코딩 재채점 결과 채점 현황 강의 질문 게시판 욕심쟁이 판다 시간 제한 메모리 제한 제출 정답 맞힌 사람 정답 비율 2 초 256 MB 36664 11853 7881 29.824% 문제 n × n의 크기의 대나무 숲이 있다. 욕심쟁이 판다는 어떤 지역에서 대나무를 먹기 시작한다. 그리고 그 곳의 대나무를 다 먹어 치우면 상, 하, 좌, 우 중 한 곳으로 이동을 한다. 그리고 또 그곳에서 대나무를 먹는다. 그런데 단 조건이 있다. 이 판다는 매우 욕심이 많아서 대나무를 먹고 자리를 옮기면 그 옮긴 지역에 ... www.acmicpc.net 골드3 난이도, 약 30%의 정답률을 가진 완전탐색 + DP 문제입니다. 문제 분석 및 풀이 이 문제를 이해하면 먼저 팬더가 대나무를 4방향으로 먹으러 돌아다닙니다. 팬더는 돌아다닐 때 이전 지역보다 무조건 대나무가 많은 지역으로

Naver Blog

[자바] 백준 N과 M 시리즈(1~4) / 백트래킹

백트래킹 연습하기에 최고로 좋은 문제인 백준 문제 N과 M시리즈입니다. https://www.acmicpc.net/problem/15649 백준 15649 : N과 M(1) 자바 풀이 package com.sosow0212.study; import java.util.Scanner; // https://www.acmicpc.net/problem/15649 (N과M (1)) public class q15649_1 { private static int n, m; private static int[] arr; private static boolean[] visited; public static void main(String[] args) { Scanner sc = new Scanner(System.in); n = sc.nextInt(); m = sc.nextInt(); arr = new int[m + 1]; visited = new boolean[n + 1]; recursion(0); }

Naver Blog

[자바] 백준 17609 : 회문 (문자열)

https://www.acmicpc.net/problem/17609 17609번: 회문 17609번 제출 맞힌 사람 숏코딩 재채점 결과 채점 현황 질문 게시판 회문 시간 제한 메모리 제한 제출 정답 맞힌 사람 정답 비율 1 초 (추가 시간 없음) 512 MB 16706 4672 3363 28.680% 문제 회문(回文) 또는 팰린드롬(palindrome)은 앞 뒤 방향으로 볼 때 같은 순서의 문자로 구성된 문자열을 말한다. 예를 들어 ‘abba’ ‘kayak’, ‘reviver’, ‘madam’은 모두 회문이다. 만일 그 자체는 회문이 아니지만 한 문자를 삭제하여 회문으로 만들 수 있는 문자열이라면 우리는 이런 문자열을... www.acmicpc.net 골드5 난이도의 정답률 29% 문제입니다. 문제 자체는 쉬운 문자열 처리(팰린드롬) 문제이나 알고리즘을 잘 짜지 않으면 시간초과가 떠서 정답률이 낮은 문제입니다. 문제 분석 이 문제는 주어지는 문자열에 대해 [팰린드롬, 유사 팰린드롬,

1 2 3 4 5 6 7 8 9