목록분류 전체보기 (396)
Just Do IT!

시간 진짜 빠르다.처음에 프로젝트 시작할때 3월이었던 것 같은데 벌써 5월이라니... 이번주는 이슈 테스트가 있어서 그 전에 기능 완성하기 위해 노력했고 드디어 기다리던 리팩토링을 시작한 주간이엇다.연휴가 껴있어서 하루 늦은 7주차 회고 시작 프로젝트 생성 추이 기능 구현 지난 회고글 에도 적혀있는데, 프로젝트 생성 추이 통계를 위헤 ProjectDailyStats 테이블을 생성했다.혼자서 구현하는 걸 고민했을 때는 스프링 배치를 적용할까, 고민이었는데 팀원들과 회의를 한 결과 별다른 이유 없이 배치를 적용하는 건 아니라는 결론을 내렸다. 그래서 혼자 적용했던 것들을 삭제하고 비동기 이벤트 처리로 변경했다. https://daydream-sy.tistory.com/399 스프링 이벤트를 활용한..

비동기 처리를 적용하는 배경 SODA 프로젝트 진행 중, 프로젝트 생성 횟수 추이를 그래프로 보여주기 위해 API를 만들어야 했었다.이 기능을 구현하기 위해 두 가지를 고민했었다.실제 DB에서 전체 조회해서 생성일에 맞춰서 카운트해서 조회하기스프링배치를 이용해 통계 테이블을 따로 생성해서 거기에 하루에 한번씩 카운트 저장하기첫 번째 방법은 너무 비효율적이라 생각만 하고 바로 지워버렸고 두번째가 적합하다고 생각했었다.왜냐면 규모가 커진다면, 하루에 프로젝트를 생성하는 횟수가 많아질 거라고 생각했고 생성할때마다 매번 통계 테이블에 저장하는 것보다는스프링 배치를 적용헤 일정한 시간에 한 번에 저장하는 게 더 나을 것이라고 생각했기 때문이다. 실제로 주말 내내 스프링 배치를 적용해서 테스트해보면서 잘 적용되는 ..

이번주도 정신없이 빙글빙글 돌아가는 일주일이였다.그냥 정신없다는 의미 = 해야할게 많다는 의미그래도 30일 이슈 테스트 전까지 얼추 기능은 완성이 될것 같아서 다행이다. 새로운 기능 구현 멘토링에서 일단 feature issue를 모두 만들어 놓고 진행하라는 조언을 들었다.어차피 나중에 가면갈수록 더 생길 수 있으니까 생각나는대로 잘게 쪼개서 이슈를 만들어놓고 작업하는 게 훨씬 편할 수 있다고.근데 그게 맞는 말이었다. 처음에는 이슈가 너무 많아서 언제 다하지, 했는데 빠르게 작업하다보니 그래도 얼추 끝났다. 그리고 월요일부터 내가 맡았던 기능은 게시글의 옵션 기능인 투표 기능. 사실 투표 기능이라고 하기엔 조금 애매한데, 카카오톡 게시판 투표하기 기능을 모티브로 구현한 기능이니까 투표라고 했..

중간 발표 끝나고 피드백들도 많이 받으면서 예상치 못한 일들이 많았던 일주일이었다.상당히 정신없는...주간이었다 ㅋㅋㅋㅋㅋ 기획을 다시 해봅시다 중간발표 이후 각 팀마다 디렉터님 면담이 예정되어있었다. 우리 팀은 매는 먼저 맞는게 낫다는 마인드로 첫번째로 고.그리고 나서 받은 피드백들로 개선하기 위해 하루를 거의 다 보냈다. 일단, 디자인 별로.누가봐도 개발자가 만든 프로젝트 같음.처음부터 끝까지 흐름을 생각해봤으면 좋겠다 등..받은 피드백들로 월요일은 순식간에 지나갔다.강의실에 있는 화이트보드로 아예 처음부터 끝까지 사용자 입장에서 어떤 디자인이 좋을지 고민해보는 등... 사실은 기획 주간에 했어야 하나, 싶지만 뭐 이미 지나간걸 어쩌겠어.걍 쿨하게 다시 프론트 디자인도 했다. 사용자 친화적..

벌서 4주차인거 실화냐고 이러다 다음달에 최종 발표 할듯.시간이 흘러 흘러 4주차...회고 시작. 프론트 배포 그동안 배포를 하지 않아서 몰랐던 사실.이제 vercel 에서는 organization 내부 repository 인 경우에는 무료로 배포할 수가 없다...!이번에 프론트 배포하려고 오랜만에 들어갔다가 알게 된 사실이다. 하기야 이해 가능하지만 무료라서 배포하려고 했는데...aws로 배포해야 하나 잠깐 고민하가 구글링해보니 개인 repository에 fork 해서 우회해서 배포하는 게 있길래 따라했다.그리고 캠프 내 다른 팀들도 그렇게 배포하길래 나도... (원래는 정정당당하게 해야 하지만 뭐...) https://daydream-sy.tistory.com/395 Vercel로 GitH..

SODA 프로젝트 중간 발표를 앞두고 배포를 해야 했다.백엔드는 배포 완료했는데, 프론트 배포를 안했다. aws s3로 배포할까 고민하다가 어차피 무료이고 몇 번 해봤던 vercel로 배포하기로 했다. 도메인 주소는 샀는데 아직 추가하지는 않았고, 일단 배포는 완료했는데 이 과정에서 생긴 일들을 기록해보려고 한다. 우선 vercel.이전에 배포했을때는 몰랐는데, github organization 내부에 존재하는 repository는 배포할때 무료가 아니었다.2주 무료 플랜이긴 한데 어차피 그 이후에 돈을 내야 했기에 우회해서 배포하는 방법에 대해 검색해보다가 다행히 찾았다. 바로 팀 Repo를 fork해서 개인 계정으로 가져온 다음, 그. repository를 통해 배포하는 것이었다.그리고 매번 업데이..

시간 진짜 빠르다. 매주 일요일마다 쓰려고 노력하는데, 그래도 이번주까지는 잘 지키고 있다.한가지 단점은 회고글 외에 다른 걸 쓰지 못하고 있다는 점ㅋㅋ 언젠가는 하겠지 뭐 아무튼, 이번주도 참 정신없게 보냈다. repository > service 리팩토링 이번 프로젝트가 각 엔티티가 너무 연관관계가 많다보니, 서비스 로직에서 여러 repository를 참조하는 경우가 많았다.그래서 멘토링에서도 하나의 서비스에는 하나의 repository만 참조하고, 다른 것들은 service를 참조하는 걸로 리팩토링하기로 정했었다.대부분 백엔드 쪽 기능 구현이 완료되면서 이번주 초반에는 백엔드 리팩토링을 진행했다. 나 역시도 repository 참조했던 부분들을 service를 참조하기 이해 변경하면서 리팩..

회고글 쓴 지 얼마나 지났나고 벌써 또 일주일이 지났는지...시간 진짜 빠르다.감기 걸려서 주말 내내 골골대다가 이제서야 글을 좀 써본다. 코드 리뷰 열심히 아무리 생각해도 객체지향스러운, 클린 코드가 잘 모르겠다. 나만 그런가.멘토링을 통해 우리 팀의 코드를 거의 전반적으로 리팩토링 해야 한다는 걸 깨달았을 때 걍 아예 엎고 처음부터 시작하고 싶다는 몹쓸 생각도 잠시 했다. 우선은 기능 구현을 다 한 뒤에 리팩토링하기로 했다. 솔직히 그게 더 나은듯. 아무튼 멘토링 받은 뒤에도 계속 백엔드 API 기능 개발에 힘썼다.그 와중에도 열심히 PR 올라오면 코드 리뷰를 했는데, 이번에 처음 해본다 사실 이전에 프로젝트 진행할 때는 바빠서 다들 PR이 올라오면 '잘 봤습니다', '굿' 이런 식으로 간..
프로젝트를 하면서 하루 종일 한 오류만 붙잡고 있던 게 정말 오랜만이다.간단히 코드 추가하는 걸로 끝났지만 간단하지 않았던 오류 해결과정이었다... 간단하게 Article을 생성하는 API를 개발하고 있었다.생성할 때 연관된 article_link, article_file 도 함께 저장되는데 그 부분에서 계속 오류가 생겼다.DB에는 잘 저장되고, 각각 조회도 잘 되는데 이상하게 create한 후 response에서는 나오지 않는 것이다. 우선, Article entity는 아래와 같다.@NoArgsConstructor(access = AccessLevel.PROTECTED)@Getter@Entitypublic class Article extends BaseEntity { private Str..
어느덧 KERNEL 최종 프로젝트를 시작하게 되었고, 앞으로 거의 두 달간 진행할 예정이다. dodream과 마찬가지로 총 3명이 진행하고, 프론트/백 둘다 진행한다.아래는 깃허브 링크.https://github.com/Kernel360/KDEV4-SODA-BE GitHub - Kernel360/KDEV4-SODA-BE: 4기 4조 'SODA' 백엔드 repository입니다.4기 4조 'SODA' 백엔드 repository입니다. Contribute to Kernel360/KDEV4-SODA-BE development by creating an account on GitHub.github.comhttps://github.com/Kernel360/KDEV4-SODA-FE GitHub - Kernel360..