본문 바로가기

전체 글193

💣 3. private 생성자나 열거 타입으로 싱글턴임을 보증하라. 보호되어 있는 글 입니다. 2024. 8. 6.
42서울을 통해 얻은 것 42서울 member가 된 지, 그러니까 inner circle을 뚫은 지 1년이 지난 후에 쓰는 카뎃 회고....ㅎ 사실 21년도에 쓴..... 와.......... 미쳤다...... 진짜 오래전이다.....ㅋㅋㅋㅋㅋㅋㅋ 라피신에 대한 글과, 그즈음의 다른 글들의 퀄리티를 보면 짐작할 수 있지만 이 시점까지의 나는 개발, 프로그래밍에 큰 뜻은 없었다. 그냥 사람은 언젠가 직업을 가져야 하고, 나는 자연과학은 너무너무너무나도 재미없고, 마침 소프트웨어학부를 들어갔으니 진짜 수학 강사할거 아니면 이거랑 관련된 무언갈 해야지.... 라는 사람이었다.  42서울의 가장 큰 메리트는 (이런 말을 관계자분들이 본다면 싫어할지도 모르겠지만) 역시 100만원이라는 지원금이었고, 항상 맡은 일에 비해 과도하게 책임감을.. 2024. 7. 20.
02. 생성자에 매개변수가 많다면 빌더를 고려하라. 정적 팩토리와 생성자는 선택적 매개변수가 많을 때 대응하기 어렵다는 공통적인 제약이 있다.꼭 내용이 들어가지 않아도 되는 선택적 매개변수가 많을 때 우리는 다음과 같은 선택지가 있다.1. 점층적 생성자 패턴, telescoping constructor pattern→ 필수 매개변수만 받는 생성자에서 선택 매개변수를 하나씩 추가해가면서 다수의 생성자를 만들어 사용하는 방식public class NutritionsFacts_tcp { private final int servingSize; // (mL, 1회 제공량) 필수 private final int servings; // (회, 총 n회 제공량) 필수 private final int calories; // (1회 제공량당) 선택 p.. 2024. 7. 19.
[kernel360] final Project 회고 이번엔 따끈따끈한했던 final Project 회고.... 2023.11.27(월) ~ 2024.03.29(금), 16주프로젝트를 설계하고 개발하고 배포하고, 기능적인 그리고 운영상의 수정 요구사항들에 대한 업데이트를 하고 다시 배포하는 과정을 모두 경험하는 기간이다. 이 전과정에서 개발을 위한 환경을 설정하고 협업 도구들을 활용하여 협업을 이루어 나간다.JDON어떠한 기술스택 으로 어떠한 강의를 학습해야하는지 고민하는 모든 개발자들을 위한, 개발자들의 네트워킹을 위한 서비스. JDON기획의도최근 기술적으로 고려되어야 할 이슈와 이를 해결하기 위해 사용하는 기술을 간접 경험하기 위해서 선택했던 방법의 하나가 채용 공고에 작성된 요구사항을 확인하는 것이었다. 효율적인 학습법이라고 생각하였고, 다른 개발자 .. 2024. 7. 17.
Redisson의 pub/sub 분산락을 사용하여 동시성 문제 해결하기 동시성 문제 해결 방법으로 분산락을 선택하게 된 이유우선 분산락을 처음 도입하게 된 과정은 커피챗 신청하기라는 기능에 대해서 동시에 여러명이 신청할 때 제한된 신청 인원수에 대한 동시성 처리를 하기 위해서였다. 하나의 서버만 존재할 때 Java의 synchonized라는 키워드를 통해 해결할 수 있지만, 해당 키워드만으로는 서버를 여러 대 사용하여 분산되어 있는 상황에서는 사용하기 어렵다는 이슈가 있다. 커피챗 신청 API는 API 서버에서 관리하는 기능으로 사용자가 많아지면 API 서버를 스케일 아웃하여 여러 서버에 대해서 운영될 수 있으므로 확장성 있는 방법을 선택하고자 분산락 처리 방법을 생각하게 되었다. 분산락은 여러 프로세스가 공유 데이터를 제어하기 위한 기술로 웹 애플리케이션 서버가 여러대이거.. 2024. 7. 17.
커버링 인덱스를 활용하여 페이지네이션 조회 속도 개선하기 기획한 서비스를 어느 정도 개발하고 나서 우리의 작고 소중한 아이에게 수많은 데이터가 쌓였을 때 성능이 어떻게 나올지 궁금해졌다.  우리가 가진 기능 중에서 지속적으로, 다른 서비스에 종속적이지 않게 쌓일 수 있는 데이터는 커피챗 도메인이었다. 또한 커피챗 서비스는  Offset-based Pagination으로 구현되어 있어서 데이터가 많아졌을 때 조회 성능이 느려질 것으로 예측되는 기능이었다. Offset-based PaginationDB의 limit, offset 쿼리를 사용하여 구분하여 ‘페이지’ 단위로 구분하여 요청/응답하게 구현페이징을 구현하기 위해서는 전체 데이터 개수를 가져와서 전체 페이지를 계산해야하고, 현재 페이지가 첫번째 페이지인지, 마지막 페이지인지도 계산해야하고, 예상치 못한 페이.. 2024. 7. 17.
Layered Architecture 설계 (feat. SOLID) JDON 아직 할 이야기가 많이 남았어요...ㅎㅎSoftware Architecture ?소프트웨어 아키텍처는 모든 소프트웨어 시스템의 기본 구조를 말하며 시스템이 제대로 기능하고 작동하도록 하는 모든 측면을 말한다. 구성요소의 설계, 구성 요소 간의 관계, 사용자 상호 작용 및 시스템에 대한 사용자의 요구를 모두 포함하는 단어이다. Layered Architecture 도입하기 왜 이런 고민을 하게 되었을까요?돌아만 가면 되는거 아닐까? 서비스가 제공하고자 하는 기능을 사용자에게 잘 전달할 수만 있으면 되는거 아닐까?ㅎㅎ겠냐고~지금의 아키텍처 이전에는 물론 나름의 계층이랄까... 그냥 패키지랄까...ㅎㅎ 나눠져있긴했지만 책임이 불분명하여 서비스를 열고 나서 사용자의 피드백을 반영하거나 새로운 기능을 추.. 2024. 7. 12.
납득이 가는 멀티모듈 구조 도입기 JDON은 멀티모듈로 구성되어있다.  1. 멀티 모듈을 도입하게 된 이유...JDON은 원티드에서 스크래핑한 JD를 기반으로 요즘 JD에 많이 언급되는 기술스택을 제공한다. 따라서 스크래핑 로직이 필요했다. 스크래핑을 구현할 때 고려할 점은 다음과 같았다. 1. 자동? or 수동?   2. API 서버와 분리? or 통합? 1-1. 자동 ? or  수동 ?우리의 결론은 '둘 다!' 였다. 우선 관리자의 편의성을 위해서 주기적으로 스크래핑을 할 수 있도록 구성하고자 했다. 그러나 주기적으로 도는 스크래핑만 구현한다면 우리가 정한 주기에 너무 종속적이고 그 사이에 스크래핑으로 데이터를 업데이트하고 싶어도 할 수 없기 때문에 수동으로 스크래핑할 수 있는 기능 또한 필요하다는 결론을 내렸다. 1-2. API 서.. 2024. 7. 6.
브라우저에서 10개 이상의 동시 요청이 보내지지 않는다면 HTTP1.1을 사용하고 있지 않은지 확인해보세요 (^__ ^).. 몇일 전... 한 페이지 안에서 웹소켓을 여러개 연결하여 connection 별로 데이터를 받아 계속 띄워줘야하는 상황에서 아무리해봐도 웹 소켓 connection 24개를 모두 완료(connection 요청부터 upgrade로 웹소켓 connection 완료까지)하는데 5초 이상이 걸린다는 팀원(a.k.a. 선생님)분의 고민을 들었다. 페이지 들어가서 5초를 기다려야 데이터도 아니고 '연결'이 완료된다...?  느리다....  웹소켓 하나를 연결할 때 약 0.01초가 걸린다. 5개도 0.1초가 안됨10개도 0.176초 근데 갑자기 20개는 5초......?!?!?!? 수치로만 봤을 때 어느 순간 갑자기 모든 연결 완료 시간이 지수함수마냥 늘어난다. 연결시간 뻥튀기의 원인 추측해보기처음에는 서버 내에서 .. 2024. 6. 20.