Tempo Tempo

1. 수레 움직이기📑 사용한 알고리즘구현📑 구현 방식에 대한 간략한 설명모든 경우의 수를 탐색하기 위해, 2중 for문을 사용해 파란색과 붉은색 수레를 각각 움직인다. 어떤 수레를 먼저 움직이는지는 완전탐색이기 때문에 상관이 없다.N이 4로 작은편이라 재귀로 풀이할 수 있었습니다.시간복잡도는 O(V^2 + E^2) 입니다.++ 이 문제에서 주목해야 할 부분은, 서로 "스위칭"이 불가능 하다는 것 입니다.ㅁ R ㅁ ㅁㅁ B ㅁ ㅁㅁ ㅁ ㅁ ㅁ다음과 같이 빨간색 수레와 파란색 수레가 존재할 경우,ㅁ B ㅁ ㅁㅁ R ㅁ ㅁㅁ ㅁ ㅁ ㅁ다음과 같이 움직일 수는 없습니다. 당연히 한 쪽 수레가 움직이려면, 빈 공간으로 움직여야 합니다.해당 부분을 주의해 수레를 움직이는 조건식을 작성해야 합니다.제 코드에서는 ..

개요6장의 내용은 put, get 연산을 지원하는 키-값 저장소 설계에 대한 내용입니다.일반적으로 사용하는 AWS의 DynamoDB, Apache Cassandra와 같은 NoSQL DB를 설계한다고 보면 쉽게 이해가 될 것 입니다.해당 장에서 중요한 점들은 다음과 같습니다.CAP 정리에 의한 분산 시스템 설계단일 서버, 분산 서버 설계 간 장/단점분산 서버 설계 시 발생하는 여러 문제들과 해당 문제를 해결하는 방법단일? 분산?먼저 put, get 연산을 통해 저장소에 키-값 쌍을 저장하고 해당 키를 기준으로 값을 불러올 수 있는 키-값 저장소를 설계한다고 생각해 봅시다.단일 서버로 구축하게 된다면, 서버 간 데이터 일관성에 대해 고민할 필요 없이 쉽게 저장소를 구축할 수 있습니다. 다만, 결국 단일 서..

문제 상황현재 A Entity가 @OneToOne으로 두 개의 Entity를(C, D)를 갖고 있다. 연관관계의 주인이 아니기 때문에, mappedBy로 가지고 있는 상태이다. 이후 필터링 기반 동적조회 쿼리를 queryDSL로 작성했다. A Entity에서 @OneToOne 연관관계를 가진 Entity에 FetchType.LAZY를 적용해놓아도, C/D Entity가 계속해서 즉시로딩되며 문제를 발생시켰다.100개의 A Entity row 조회였지만, respnose 시간이 2.18초로 매우 낮은 성능을 보여주었다...(평균적으로 2.5초 정도 걸렸다.)원인먼저 결과부터 말하면, JPA @OneToOne 연관관계에서 mappedBy로 Entity를 가지고 있는 Child Entity는, 항상 Paren..

Http Standard로는, Get 요청에는 Body가 존재하지 않는다. 모든 데이터를 QueryString으로 처리할 뿐이다. 하지만, 복잡한 검색 조건이 담긴 필터링은 JSON 필터 정보들을 담을 공간이 필요하다. 이때 검색을 위해서는 HTTP METHOD GET을 써야할까, POST를 써야할까?StackOverflow에서도 POST 요청을 사용하는 것이 좋다고 하지만, 확신을 가질 수 없었다.https://stackoverflow.com/questions/20550514/post-or-get-in-a-search-form그래서 HTTP Protocol에 대한 RFC 문서를 찾아보며 각 METHOD를 사용할 때를 가정한 후 결정을 내렸다.GETGET을 사용한다. 하지만, 일반적으로 Get 요청에는 ..

"페어링 중고거래 플랫폼"이라는 프로젝트를 진행하면서, 발생한 기술적 이슈들을 어떻게 해결했는지에 대해서 기술 블로그를 만들게 되었습니다. 페어링 중고거래 플랫폼 2024.02 - 진행 중 6인 프로젝트 프론트엔드 2명, 백엔드/인프라 4명 에어팟과 같이 각 부분별로 중고 거래글을 올리는 선택지와 다른 사람들과 합쳐 한 개의 상품으로 판매할 수 있는 선택지를 줄 수 있는 통합 중고거래 플랫폼입니다. Jenkins, Docker를 이용한 CD 환경 구축을 통한 기존 수동 빌드 시간 제거 Kafka를 통한 애플리케이션 레이어 / 메세지 브로커 분리, 영속성 보장 Kafka-ui를 도입해 기존 토픽/컨슈머 확인 시간을 5분 → 10초 이내로 단축 Cloudflare를 활용한 SSL/TSL 인증서 적용 및 DD..

1. 도넛과 막대 그래프 📑 사용한 알고리즘 BFS 📑 구현 방식에 대한 간략한 설명 새롭게 생성된 정점은 쉽게 구할 수 있습니다. 해당 정점으로부터 나가는 간선이 2개 이상이면서(도넛 모양 그래프, 막대 모양 그래프, 8자 모양 그래프의 수의 합은 2이상입니다. 라는 조건이 있음), 들어오는 간선이 0개인 정점을 찾으면 됩니다. 그렇게 시작 정점을 구한 후, 해당 정점으로부터 BFS 방식으로 분기하며 각 그래프의 종류를 찾았습니다. 먼저 8자 그래프인 경우, 임의의 한 정점에서 시작할 경우 탐색하다 보면 간선이 2개 연결된 정점이 무조건 존재합니다. 그래서 연결리스트 탐색 중 연결된 정점 개수가 2개 이상이면 8자 그래프로 판단했습니다. 도넛 그래프인 경우, 탐색하다보면 무조건 이미 방문한 정점을 탐색..

기존에 알고있듯이 @OneToMany와 같은 어노테이션이 붙어있는 필드 엔티티는 FetchType.LAZY가 기본값이고, @ManyToOne과 같은 어노테이션은 FetchType.EAGER가 기본값이다. FetchType.EAGER가 붙어있는 필드 엔티티는, 해당 필드를 포함한 엔티티를 조회하는 순간 해당 필드 엔티티도 조회하게 된다. @xxToOne 연관관계인 필드 엔티티에는 FetchType.LAZY를 붙이는게 대부분 좋다는 것을 김영한님 강의에서도 들어서 알고는 있었는데, 붙이지 않고 구현한 경우가 생겨 트러블 슈팅을 하게 되었다. 지금 개발중인 비즈니스 로직에는 ChatRoom(채팅방 정보), UserChatRoom(채팅방에 참여하고있는 사용자 정보), Chat(채팅 메세지 정보) 총 세개의 엔티..

1차원 냅색 + 그래프 개념이 포함된 문제이다. 첫번째 아이디어 : 한 명이 사탕을 뺏기면 친구들도 다 뺏긴다 -> BFS 탐색으로 친구들끼리 묶을 수 있다. 친구들끼리 묶어 하나의 입력으로 만든다. 그 후, 배낭 문제처럼 풀이한다. 예시를 들어보자. 각 사람마다 사탕의 개수를 갖고 있는 배열을 candies[]라고 하자. N번째 사람을 생각해봤을 때, 해당 사람과 연결된 친구가 없을 경우 무게가 1이고 사탕의 개수가 candies[N]인 배낭 하나로 생각할 수 있다. (이 부분을 생각하지 못해서 틀렸었다.. 친구 관계가 없는 사람도 있음) N번째 사람이 연결된 친구가 있을 경우, (자신 + 친구들의 수)만큼의 무게이고 사탕의 개수가 (candies[N] + candies[친구들의 idx])인 배낭 하나..