개발자가 되는 과정

Elastic Stack ELK: Elasticsearch, Logstash, Kibana Elasticsearch: 검색 및 분석엔진 Logstash: 서버 사이드 데이터 처리 파이프라인, 여러 소스의 데이터를 수집하여 변환한 뒤 elasticsearch 에 전송 Kibana: Elasticsearch 의 내용을 차트와 그래프를 이용해 데이터를 시각화 Beats: 경량의 단일 목적 데이터 수집기 제품군 Elastic Stack: ELK + Beat ELK 설치하기 프로젝트를 하면서는 별도의 EC2에 docker 에 설치하였다. elk docker 설치 참고 레포짓토리 elk 서버에 logstash, elasticsearch, kibana 를 설치 logstash, kibana 는 elasticsearc..

서브모듈 서브모듈은 Git 의 기능 "Git 저장소 안에 다른 Git 저장소를 디렉토리로 분리해 넣는 것" 시작하기 $ git submodule add 서브모듈경로 시작하면 .gitsubmodule이 생기며 설정정보가 들어간다. # .gitsubmodule [submodule "test-submodule"] path = test-submodule url = https://github.com/knae11/test-submodule.git 서브모듈에 새로운 내용을 추가하고 싶다면 서브모듈에 파일을 추가하고, 해당 경로로 가서 commit, push 를 한다. 서브모듈에서 git 관리는 본 프로젝트와 따로 관리된다. 서브모듈에 새로운 내용이 반영되었다면, 본 프로젝트 커밋 목록에 서브모듈이 나타난다. 해당 파..

🧎‍♀️READY 어떤 팀 프로젝트를 하고 싶었을까? 단지 사용자가 있는 서비스 될 수 있는 어떤 프로젝트를 해보고 싶었다. 작더라도 사용자가 있는 서비스를 만드는 한 과정을 경험하고 싶었다. 그런 의미에서 잘 모르는 사용자가 있을 것이라는 생각으로 기업 프로젝트를 선택하게 되었다. 팀 프로젝트를 시작하기 전부터 고민이 많았던 부분은 회의였다. 그동안 이런저런 회의를 하면서 회의가 잘 진행되기 위해서는 어떻게 해야 좋을까 고민이 많았었다. 팀 프로젝트를 하면서 회의를 잘하는 방법을 알아갈 수 있길 바랐다. 🚶‍♀️GET STARTED 초반에는 정해진 것이라고는 주제밖에 없었다. 사실 주제조차도 모호했다. 그랬기에 프로젝트를 이해하고 있는 관점도 생각도 다 달랐다. 주제를 구체화하는 부분조차 상당히 어려웠..

배경 팀 프로젝트를 하면서 비지니스 로직 이외에 code formatting 과 같이 다른 부분에서 리뷰를 남기거나 신경을 써야하는 것이 또 다른 낭비라고 생각했다. 모두가 좀 더 깔끔한 코드 형태를 보면서 비지니스 로직에 집중했으면 하는 마음에서 린트 설정을 알아보게 되었다. 실제로 근로에서는 kotlin을 사용하는데, ktlint를 사용하여 코드 컨벤션이 맞지 않으면 커밋 자체가 되지 않도록 설정되어 있다. 비지니스 로직에 집중 깔끔한 코드 스타일을 유지 intelliJ 자동정렬에서 개행이라던지, 메소드 간 2줄이 띄워지는 형식들은 잡아주지 못함 정적 분석도구 찾기 ktlint와 같은 것들을 찾다보니, sonarlint, checkstyle 등이 나왔다. 확실히 모르지만 sonarlint는 개인이 설..

배경지식 메세지 브로커 이벤트 브로커로 역할 불가 메세지 기반 미들웨어 아키텍처 PRODUCER, CONSUMER 메세지를 받아서 처리하고 나면 삭제되는 구조 래디스, 레빗엠큐 이벤트 브로커 메세지 브로커로 역할 가능 서비스에서 나오는 이벤트를 이벤트 큐에 저장함 딱 한번 일어난 이벤트를 저장하여 → 단일진실 공급원으로 사용 장애가 일어난 시간부터 다시 처리가능 많은 실시간 데이터를 처리가능 장부를 딱 하나만 보관하고 인덱스를 통해 개별 엑세스를 관리 업무상 필요한 시간동안 보관 가능 카프카 큐와 소비자의 연관관계 OneToOne 하나의 큐에 하나의 애플리케이션이 있음 OneToMany 하나의 큐에 여러개의 애플리케이션이 있음 Redis vs RabbitMQ vs Kafka 비교1 브로커 스케일 데이터 ..

1. OneToMany 단방향 매핑 JPA 에서 연관관계 설정 객체지향관점: 일대다 단방향이 깔끔 → 부가 업데이트 쿼리가 무조건 나가게 됨. 기술 JPA 관점: 다대일 단방향이 깔끔 → 객체의 입장에서 참조관계가 DB 테이블 구조 처럼 됨. 합의: 다대일 양방향 → 편의 메소드에 대한 고려를 해야함. 배경 양방향을 설정하면 편의 메소드를 고려해야하며, 순환참조에 빠지지 않도록 주의해야 한다. 양방향을 설정하는 것(서로간의 단방향을 2개를 설정하는 것)은 객체지향의 입장에서도 약간 이상하다고 느껴짐 개발자가 신경써야할 포인트가 늘어나기 때문에 실수할 여지가 많아짐 따라서 단방향 설정이 좋다고 하는데 다대일 단방향은 객체처럼 객체를 사용하기 어려움 그렇다면 일대다 단방향은 성능 면에서 안 좋다고 하는데 왜..

수업 A객체 → B 객체 참조 : 이동가능 B 객체 → A 객체 참조가 없다면 : 이동불가 하지만 테이블은 join으로 이동가능 (항상 양방향) 연관관계의 주인: 객체와 객체 사이의 관계 (실제 DB와 매핑하면서 주인을 정해야 함 → 주인 대신 외래키 관리자 라고 해보자!) 연관관계: 다대일, 일대다, 양방향, 일대일 다대일 단방향 ManyToOne : 다대일 JoinColumn: 해도되고 안해도됨(foreign key의 이름을 지정해주는 역할) → 생략된다면 엔티티이름+id로 지정됨 단방향관계 엔티티 Station -> Line: 가능 Line -> Station: 불가능 테이블 station -> line: 가능 line -> station: 가능 지하철에 Line 정보추가 → 지하철입장에서는 다대일..

JPA 왜 사용하는가? 패러다임 불일치(객체지향 VS 관계형 데이터베이스) 객체는 방향성이 있는데, 테이블은 방향성이 없음 객체답게 모델링할수록 RDB에 저장하기 위해 매핑작업만 늘어남 엔티티 신뢰문제 원하는 내부 필드를 다 가지고 있는지 확신할 수 없다. 널포인터 익셉션이 일어날 수 있다! 자바 컬렉션에 저장하듯이 DB에 저장할 수는 없을까? JPA(Java Persistence Api) ORM(Object-Relational Mapping, 객체 관계 매핑)JPA를 사용하면? SQL 중심적인 개발에서 객체 중심적인 개발이 가능 생산성 향상 (비지니스 로직에 더 집중가능) 유지보수 신뢰할 수 있는 엔티티 패러다임 불일치 문제 해결 JPA의 핵심개념 영속성 컨텍스트, 연관관계 매핑 JPA 사용에 필요한 ..