Coding Diary

1. 채팅 기능을 왜 구현하게 되었나? 현재 진행하고 있는 프로젝트에서 사용자들끼리 1:1로 대화를 하는 기능이 필요하다. 이를 소켓을 활용한 채팅 기능이 아닌 그냥 일반적으로 글을 주고 받는 쪽지 형식으로 구현해도 되긴 했으나 소켓으로 채팅기능을 구현해보는 걸 이번 기회 아니면 언제 해보겠냐는 생각에 적용해보기로 하였다. 다행히 프론트엔드 개발자 분도 동의해주셨다. 2. 근데 socket이 뭔데 추후 정리 3. 채팅 기능 구현을 위한 의존성 implementation 'org.springframework.boot:spring-boot-starter-websocket' 4. socket 처리를 위한 핸들러 추후 정리 5. 내가 구현할 채팅 환경 및 이를 위해 필요한 엔티티 정리(+레포지토리) 1) 환경 ..

문제 및 코드 1. 생각 도출 // 조건 // 가로는 세로와 같거나 세로보다 더 길다 // 생각 // yellow의 약수를 구해서 약수 짝끼리 yellow 모양이라고 가정하고 가로, 세로, brwon을 구해본다 // yellow의 약수를 모두 구해서 약수 짝끼리 살펴 봐야 하니 완전탐색이 아닐까 // yellow보다 작은 수를 돌면서 약수를 구한다 // 약수가 1이다 // 가로 = yellow + 2, 세로 = 3 // 해당 가로세로의 넓이에서 yellow를 뺀 후 brown을 구한다 // 구한 brown이 주어진 brown과 같으면 // 더 긴 걸 가로로 하고 작은 걸 세로로 한 후 종료한다 // 약수가 1이 아니다 // 첫 번째 약수 + 2, 두 번째 약수 + 2 중 더 긴 것이 가로, 짧은 것이 세..

문제 및 코드 1. 생각 도출 모든 경우의 수를 구해서 해당 경우가 소수인지 판별해야 한다. 여기서 모든 경우의 수란 1, 12, 123, 13, 132, ... , 3, 31, 312, 32, 321 과 같이 각 숫자를 연결한 수를 의미한다. 모든 경우의 수를 구해야 하니 완전 탐색이 필요한 상황임을 알 수 있다. 그럼 어떻게 완전 탐색을 진행할 수 있을까? 배열 원소 하나를 기준으로 잡고 그 원소 뒤에 나머지 원소를 붙여 나가면서 모든 경우를 구한다. 이렇게 하면서 배열을 돌면 모든 경우의 수를 구할 수 있다. 그리고 모든 경우의 수를 set에 저장한 다음 set을 돌면서 각 원소가 소수인지 아닌지 판별한다. 경우의 수를 만들다 보면 중복 경우의 수가 나타날 수 있으니 set을 사용해서 저장한다. 그..

문제 및 코드 1. 생각 맨 처음에 오름차순 정렬 후 적은 사람들끼리 태우자! 이렇게 생각했는데 틀림... 2. 회고 한 구명보트에 2명만 탈 수 있다는 제한을 보지 못하고 문제를 끙끙거리며 풀어나갔다. 탐욕 분류니까 정렬해서 몸무게 적은 사람들부터 태우면 되겠군... 이러면서 풀었는데 테케는 통과해도 정답처리가 안 됨. 그래서 도저히 왜 그런지 몰라서 자세히보니 2명만 탈 수 있다는 제한이 있었음. 앞으로는 제한 사항을 잘 보자. 그리고 구명보트 수를 최소한으로 하기 위해 몸무게를 오름차순으로 정렬하고 제일 몸무게 적은 사람과 많은 사람을 함께 태워버리자는 탐욕법은 그래도 이해가 되었음... ---- 오름차순 정렬한 다음 몸무게 적은 사람들끼리 먼저 태우면 되지 않을까? 하면서 풀었는데 테케는 통과돼도..

문제 및 코드 회고 그리디로 어떻게 접근해야 하는지 판단이 잘 서지 않았음 그러다 다른 풀이를 참고해서 그리디를 적용해서 맨 앞에서부터 제일 큰 수를 찾아나가면 되겠다는 생각을 하게 되었음. 근데 그러면 제일 큰 수를 어떤 범위에서 찾아야 하지에 대한 생각을 하게 됨. 이때 총 만들어야 하는 숫자의 길이를 참고해서 해당 숫자의 길이의 맨 앞 숫자부터 구해나간다는 생각으로, 특정 시작점부터 만들어야 되는 숫자의 남은 길이를 남겨둔 곳까지 범위 중 최댓값을 찾아나감. 그 끝이 k+i이라고 할 수 있음. 다른 풀이 보고 그래도 이해는 되었는데 시간이 엄청 오래 걸렸다... 기억 number.charAt(j) - '0' 이렇게 숫자형태의 문자에서 '0'을 빼주면 int 형의 값을 얻을 수 있다. 체크 풀이 횟수..

문제 및 코드 회고 상하로 이동해서 answer에 더해 주는 부분은 이해가 된다. 그런데 좌우로 이동하는 부분이 2시간 30분동안 생각을 해봐도 이해가 안 된다.... 다음에 또 봐야 할듯 체크 풀이 횟수 시간 정답 여부 참고 여부 1 2시간 30분 O

1. 정의 완전 이진 트리로 최소 힙이라면 작은 값이 위쪽에 있고 최대 힙이라면 큰 값이 위쪽에 있다. 즉, 최소 힙이라면 부모 노드의 키 값이 자식 노드의 키 값보다 작거나 같다. 최대 힙이라면 부모 노드의 키 값이 자식 노드의 키 값보다 크거나 같다. 2. 특징 우선순위큐를 위해 사용되는 자료구조 중복된 값을 허용한다 3. 구현 배열로 구현한다 구현의 용이성을 위해 트리의 인덱스를 1로 시작한다 왼쪽 자식의 인덱스 = 부모 인덱스 * 2 오른쪽 자식의 인덱스 = 부모 인덱스 * 2 + 1 부모의 인덱스 = 자식의 인덱스 / 2 4. 연산 1) 삽입 새로운 요소가 들어오면 완전 이진 트리의 맨 뒤에 일단 삽입을 한다 삽입한 새로운 노드를 부모와 비교해가면서 최소 힙 혹은 최대 힙에 맞게 교환해 나간다 ..

문제 및 코드 회고 우선순위큐를 사용하는 카테고리여서 우선순위큐를 사용하기도 했지만 문제를 잘 보면 우선순위큐를 사용하면 좋겠다는 생각이 든다 우선순위큐 만들어서 손쉽게 풀어서 오 괜찮은데? 이러고 제출했는데 4개의 테케 통과가 안 되길래 뭐지 이러고 살펴보니 제한사항을 내가 제대로 보지 않았다. 스코빌 지수를 만들 수 없는 경우를 고려 했어야 했다. 기억 우선순위 큐 생성 PriorityQueue pq = new PriorityQueue();//작은 수가 우선순위 갖는 우선순위 큐 PriorityQueue pq = new PriorityQueue(Collections.reverseOrder()); // 큰 수가 우선순위 갖는 우선순위 큐 체크 풀이 횟수 시간 정답 여부 참고 여부 1 40분 O

문제 및 코드 회고 일단 가장 먼저 들었던 생각은 아래와 같다. 이중 for문 쓰면 시간초과 날 것 같아서 스택이나 큐로 풀려고 했다. 근데 이중 for문 써도 시간초과 안 나네..? 배신감을 느낌 큐로 해야하는지 스택으로 해야 하는지 갈피가 안 잡혀서 엄청 고민하다가 큐로 했는데 테케 1만 통과하고 다 틀림... 그래서 결국 다른 풀이를 봤음 스택으로 잘 풀어져있는 코드가 있었음. 나는 계속 주식 가격을 집어 넣고 빼고, 가격이 오른 거를 계속 유지하려고 하고 그랬는데 발상의 전환으로 가격 자체가 아니라 가격의 인덱스를 집어 넣고 빼고, 가격이 떨어진 거만 먼저 구한 다음 나중에 가격이 계속 유지되었던 것만 구하는 방식으로 풀이가 구현되어 있었음. 어떻게 이런 생각을 하지? 더보기 // prices를 ..

문제 및 코드 회고 큐를 이용해야 되는 건 알았는데 각 트럭이 다리 길이를 지나는 시간을 어떻게 측정해야 하지?에 사로잡혀서 엄청 헤맸다. 각 트럭마다 시간을 잴 필요는 없었고... 새로운 트럭을 살필 때 총 무게가 견딜 수 있는 무게를 넘는다면 기존의 트럭을 이동시키기 위해 더미 값을 큐에 넣어주는 아이디어가 새로웠다. 트럭의 상황에 맞게 케이스를 잘 나누는 것이 핵심 기억 큐 생성 Queue q = new LinkedList(); for문을 돌면서 for문의 index를 통제하고자 할 때는 for문에 while문을 사용할 수 있다 체크 풀이 횟수 시간 정답 여부 참고 여부 1 엄청 오래... O