Sparta_프로젝트

한 주의 흐름1) 한 일프로젝트 명: 자기소개 페이지 생성 및 기능 구현필수 작업: 각자 자기소개 페이지 구현, 회원가입 및 로그인 기능추가 작업: 블로그 링크, 네비게이션 바 등을 추가2) 느낀점대현 - 팀장의 역할이 중요한 것 같다고 느꼈다. 발표가 생각보다 떨렸다

웹 개발을 오랜만에 해봤다. css는 건들지도 못하고 일단 html 쪽에서 기억나는 것들과 강의를 참고해서 개인별 자기소개 페이지를 만들었다. 완성된 페이지는 이러했다. 솔직히 정렬도 엉망이고 디자인도 구리지만, 짧은 시간 안에 다른 팀원 분들도 열심히 만들어주셨는데

때는 24년 12월 20일 금요일, 나는 드디어 기초 프로젝트 과제 팀을 배정받았다. 그리고 뉴스피드를 만들라는 과제를 부여받고, 사실상 본격적인 팀 프로젝트를 처음 해 보았다.대학 시절에도 이런저런 프로젝트를 만들기는 했으나 Spring Boot를 사용한 본격적인 프

요 몇 주 사이에 나는 TIL을 많이 놓쳤다. 스스로에게 변명해보자면 시간이 정말 부족했다. Spring Boot 숙련 주차부터는 할 일이 너무 많아졌고, 기초 프로젝트를 시작하면서는 정말 페어코딩으로 하루 10시간을 넘게 보냈기 때문이다. 아무튼 그러한 핑계가 있었다

1\. 한 주의 흐름1) 한 일프로젝트 명: 뉴스피드 프로젝트필수 작업: 유저 CRUD, 게시판 CRUD, 로그인 기능 및 인증, 친구추가 기능추가 작업: 댓글 CRUD, 좋아요 기능, 정렬 기능2) 느낀점주양 - 본격적인 협업을 하면서 처음 제대로 된 의견 충돌이 나

어제부터 2번째 팀 프로젝트가 시작되었다. 저번 과제에서 나는 필수구현 과제만 겨우 성공하고 도전 과제를 잃었다. (눈물) 그래서 이번 팀 프로젝트에서는 그 때 못 했던 도전 과제들을 놓치고 갈 수 없었고, 격차가 벌어지는 걸 방지하기 위해 조금 더 많이 공부하고 조

아웃소싱이란? 외주 업체에게 짧은 단위로 개발을 맡기는 것이라고 합니다.우리는 그리하여 1주일, 아웃소싱 배달앱 개발을 위해 달려갔다.사실 다들 달리는데 나 혼자서 기어가다가 여러 번 넘어졌다아무튼, 그래서 어제 회원가입을 작성하고 오늘은 로그인, 로그아웃, aop까지

이제 발표를 거의 눈앞에 두고 있다! 이번 과제를 진행하면서 나는 스스로가 부족한 점을 많이 깨달았고, 그러면서 해야할 일을 추가로 더 알게 되었다. 바로 팀 과제 전체를 한 번 돌아보고, 모르는 부분을 조금 더 정리해야 한다는 것이다.물론 이전에도 했어야 맞다. 하지

초기부터 gitignore 등을 사용해서 깃허브 컨플릭트 확률이 낮아서 편했고, 좋았던 것 같다.기존 프로젝트보다 커밋을 많이 했고, 풀리퀘스트도 많이 했어서 그 부분이 좋았다.팀원들끼리 분량 분배나 다른 것들은 많이 소통을 했으나 코딩 방식 통일이 안 되었어서 발표

저번 주 금요일부터 본격적으로 플러스 프로젝트가 시작되었다.그리고 나는 최종 프로젝트 부팀장 신청이 저번 주 월요일까지인 걸 모르고 놓친 바보였다. 뭐 면접시간 놓친 바보니까 그러려니 하면서 혼자 울고 있다.아무튼, 그리하여 속상한 마음을 딛고 플러스 주차 프로젝트를

어제 최종 프로젝트를 위해 파트분배를 했다. 이번 최종 프로젝트에서는 버전별로 나누어 작업을 시작할 예정이며, 우리의 주제는 취준생을 위한 웹페이지 만들기이다. 난 저번 과제에서 JWT 토큰과 Spring Security를 이용한 인증인가를 구현했고, 그와 더불어 A

어제 계속 리다이렉트에 대한 문서화를 하고, 정리를 하고 공부하다가 결론적으로 현재 버전에서는 RedirectView를 사용하는 것으로 결론이 났었다.그래서 보아하니 더미데이터를 사용하게 되면 그나마 레포지토리나 서비스를 사용하는 시스템이지만 그것도 안 쓰는 경우에는

요새 며칠 계속 문서화 작업만 하니까 정말 너무 너무 너무! 개발이 하고 싶다. 그래서 개발 관련 공부를 문서화 하는 걸 하기로 했다. 저번에는 리다이렉트에 대한 개념을 공부하면서 정리를 했었는데, 이번에는 아예 동시성 제어의 대한 공부를 하면서 정리를 해보기로 했다.

이제 V2를 만들 때가 왔다. 동시성 제어!!!그리고 이 사이에 우리에게 나름 큰 이슈가 있었다. 바로 크롤링 이슈였다.어제 저녁, 갑자기 시간이 조금 남은 나는 크롤링을 덥석 물었다. 근데 크롤링은 아무나 못 한다네!?!?!?robot.txt 사이트로 합법적인 크롤링

저번 주에 낙관적 락에 대한 테스트 코드 작성을 겨우 끝냈는데, 이제는 비관적 락이다. 하낙관적 락으로 끝내도 될 거 같지만, 자꾸만 이유를 가져다 대라는 팀장님의 말,말,말... 나는 왜 이걸 지금 이렇게 고 있는가... 필요 없지 않는가...? 결국 돌골돌아서

동시성을 결국 낙관적 락으로 끝낼 거 같다는... 그런 결론이 나왔으나 결과를 보고 또 다시 팀 회의를 해본 결과 정합성을 위해서 비관적 락으로 하되, 성능을 개선하자는 이야기로 발전이 되었다.오늘 오전까지 계속 그걸로 이것저것 찾아보는데 조회를 먼저 하고, 저장을 나

정말 수면이 하고 싶지만, 즐겨찾기까지는 오늘 다 마치고 잠들고 싶다. 얼른 구현해야지이이..나는 즐겨찾기 코드를 보고, 기어이 오늘은 일찍 자기 글렀다는 걸 깨달았다. 현 시각 벌써 밤 9시 30분, 하지만 나는 해야한다.일단 망했다는 생각이 난 이유는 즐겨찾기로 조

밤이 지나고, 나는 바보라는 알림이 깜빡깜빡했다. 왜냐, 리스트가 필수가 아닌 내 선택이라는 걸 아침에 다시 깨달았기 때문이다.새벽 2시까지 공부하고 9시에 머어엉..하니 일어나서...바보! 바보! 바보!어제 새벽에 한 무의미한... 건 아닌 씨름은 서브쿼리 마스터가

이제 검색 기능의 기본 뼈대는 만들어졌으니, 다시 비관적 락의 성능개선을 목표로 작업을 이어가보려한다. 1. 비관적 락을 빠르게 하는 법을 찾기 1. 내 머리로 생각해보기 일단 비관적 락을 빠르게 하려면 락이 걸리고 작업이 진행될 때까지 대기시간이 걸리기 때문이다.

0. 서론, 리팩토링 어제 그제 했던 작업들 중 풀리퀘 올렸을 때 리팩토링 리뷰가 들어온 게 있어서 몇 가지 수정을 하고, 이후에 추가적인 개선을 할 필요가 있는 부분을 정리해보려고 한다. 그리고 한 가지 중요한 부분은 내가 작업물이 겹쳐서 풀리퀘가 어마어마하게 길어

오늘은 팀원 모두 모여 엘라스틱 서치에 집중하는 시간을 가지고 있다. 현재 팀원 한 분이 엘라스틱 서치를 설치하고 그 코드가 머지 되어야 하기 때문이다. 그렇게 되면 우리는 나머지 작업을 하기 위해 엘라스틱 서치를 다 설치를 해 줘야 한다.키바나와 엘라스틱 서치를 설치

저번 주에 동시성 코드를 작성하려 했는데 마침 엘라스틱 서치를 하느라 놓치는 바람에 오늘 그걸 다시 하기로 했다. 동시성 코드는 참 알 수가 없다. 테스트 코드에서 일단 제일 어렵고 제일 중요한 부분부터 작성을 시작해보기로 했다. 주말에 조금 짬을 내서 해봤는데 계속

이제 나는 결합도도 낮추고, 테스트 코드도 작성했고.. 팀원 간의 보안 문제도 검수 끝냈고, 여기저기 코드 리뷰도 어느정도 했고..? 그러다보니 엘라스틱 서치를 할 때가 된 거 같다.Elasticsearch란 Apache Lucence 기반의 JAVA 오픈소스 분산 검

얼마 후 우리에겐 중간발표가 있다. 그래서 나는 다시 한 번 비관적 락을 걸었을 때 속도와 현재 개선된 비관적 락으로 실행했을 때 속도 차이가 알고 싶었다. 0. 큰 헛짓거리, 동시성 속도비교 나는 그 동안 뭔가 큰 착각을 하고 있었던 것이 분명하다. 동시성 제어를

이제 성능 개선 동시성 쪽은 거의 막바지에 이르렀다. 이번에는 Redis를 활용해서 분산 락으로 성능을 개선해볼 수 있을지 해 볼 예정이다. 일단은 구현해보고 이게 잘 돌아가는지, 헛점은 없는 지 다양한 관점에서 볼 예정이다. 1. Redis 구현하기 사실 우리 코드

새벽 내리 분산 락이 적용이 제대로 안된 걸 보고, 아무래도 동기화가 직후에 되는 문제가 크다고 판단이 되어 이번에는 배치를 써보려고 한다.집계테이블로 업데이트할 때 어느정도 값이 쌓이고 업데이트 되도록 하는 것이다.와아아... 부하 테스트가 계속 터져버리고 있다. 심

엘라스틱 서치 데이터 스트림을 사용해야 하는데, 이 개념 자체가 나는 생소했기 때문에 도대체 뭐지? 싶어서 이곳저곳 찔러봐야 했다. 일단은 공식 문서를 참고하면서 어떤 것인지 탐구해보는 시간을 가져야겠다. 일단 공식 문서랑 이것저것 찾아본 결과, 키바나로 연결 후에

지금 동시성 제어를 무려 나는 5가지를 통해 시도해봤다. 그리고 오늘은 그 결론을 내보고자 한다. 1. 동시성 제어의 결론, Redis 사용 후 스케줄러를 쓰자 1. 동시성 제어 리팩토링이 필요한 이유 나는 현재 조회 수를 Redis에서 관리하여서 원자적 연산을 통

어제 드디어 개발이 끝나버렸다! 와아아ㅏㅇ!!!이제 우리에겐 리팩토링, 테스트코드 추가하기 등이 남아있다. 그리하여 나는 아래의 코멘트를 반영하여 조회수 카운트를 AOP로 만드는 작업을 해보기로 했다.이거... 정말 생각 이상으로 괜찮을지도 모른다. 지금 내가 고민하던

발표 날 아침, 갑자기 동시성 제어가 발표에서 빠져버렸다는 이야기를 들어버렸다.(눈 커짐) 네?들어보니 Redis는 정합성에 문제가 없지만 동기화를 할 때는 정합성이 제대로 들어가질 않았다는 게 이유였다. 음...? 이미 저번에 Redirect 예외처리를 할 때 페이지

이제 프로젝트 주간이 시작되면서 요구사항 명세서를 작성하기로 했다.프로젝트 인원은 5명, 내가 담당할 파트는 일단 상품 파트이다. 솔직히 아침부터 저녁까지 쭉 회의, 회의, 또 회의만 한 거 같아서 조금 머리가 아팠다. 하지만 그래도 얻어가는 건 있었던 거 같다.SA를

우리의 입문 프로젝트는 배달앱이다. 그리고 파트는 도메인별로 나누면서 각각 담당을 정했는데 나와 다른 팀원 분은 상품(음식) 파트를 맡았다. 도메인별로 한 명이 해도 되겠지만 우리의 경우 상품이 입점사(가게)와도 연관이 되어있고, 또 상품에 대한 카테고리까지 설정할 계

API 명세서를 작성할 때, 권한별로 URL을 만드는 게 나을지, 아니면 그냥 Role 체크만 하는 방식으로 하는 게 맞는지에 대한 이야기가 나왔다.위와 같은 방식으로 url이 구성된다면 Restful하지 않은 거 같다라는 이야기였다.하지만 권한별로 API의 url이

오늘 오전에는 알고리즘이 끝난 후 Infisical이라는 secret maneger시스템과 Flyway라는 DB관리 시스템이 적용된 프로젝트를 각자가 실행해보는 시간을 가졌다.Infisical은 개발할 때 중요한 설정파일들을 안전하게 공유할 수 있는 일종의 클라우드 시