편집 시간: 2022년 5월 14일 오후 10:33 코드 Algorithm/9465.py at main · Junroot/Algorithm 풀이 일단, 2줄의 스티커이므로 각 열마다 하나의 스티커만 선택할 수 있다는 것을 알 수 있었다. 그래서 처음에는 각 열마다 지그재그로 스티커를 선택한 두 가지 경우중 최대값이 정답이라고 생각했다. 하지만, 아래와 같이 한 열을 포기하고 선택하는 경우가 더 최대인 경우가 있었다. x x x 그래서 dp로 문제를 접근했다. f(x, y): 0번열부터 x열까지에서 x열 y행을 마지막으로 선택하는 경우의 최대값...

편집 시간: 2022년 4월 12일 오후 3:02 코드 Algorithm/9328.py at main · Junroot/Algorithm 풀이 bfs를 이용하면 쉽게 해결할 수 있다. 이동하다가 문을 만났을 때, 열쇠가 있는지 판별하고 있다면 이동하고, 없다면 열쇠를 기다리는 문 컬렉션에 추가 하는 형태로 문제를 풀었다.

편집 시간: 2022년 3월 24일 오후 1:45 코드 Algorithm/9252.py at main · Junroot/Algorithm 풀이 기존의 LCS 문제에서 dp원리를 이해하면 쉽게 해결할 수 있다. dp에 저장된 값을 보고 어떤 문자가 사용되었는지 확인하면되는데, 현재 위치에 저장된 값이 (왼쪽 위의 값) + 1인 순간이 해당 문자를 사용한 것이다.

오답 여부: o 편집 시간: 2022년 2월 24일 오후 6:02 코드 Algorithm/9251.py at main · Junroot/Algorithm 풀이 잘못된 풀이 문자열 하나에 대한 dp로 접근했다. 첫번째 문자열로 dp를 한다면 아래와 같이 접근할 수 있었다. f(x): x번째 문자열을 마지막으로 가지는 str2과의 (LCS, 마지막으로 사용한 index) f(n) = max( f(m) ) + 1 {m | m은 정수, 0 ≤ m < n, f(n)의 index > f(m)의 인덱스} max는 LCS가 같다면 마지막으로 사용한 index가 더 작은 것을 우선으로....

편집 시간: 2022년 2월 18일 오후 6:45 잘못된 풀이 first = input() second = input() cache = [(0, 9999) for _ in range(len(first))] def find_indexes_in_second(char): result = [] for i in range(len(second)): if second[i] == char: result.append(i) return result for i in range(len(first)): char = first[i] indexes = find_indexes_in_second(char) if len(indexes) == 0: continue cache[i] = (1, indexes[0]) for j in range(i): max_length = cache[j][0] last_index = cache[j][1] for index in indexes: if last_index < index: if cache[i][0] < max_length + 1: cache[i] = (max_length + 1, index) break elif cache[i][0] == max_length + 1 and index < cache[i][1]: cache[i] = (max_length + 1, index) break print(max(cache)[0])

날짜: 2022년 5월 24일 오후 7:27 코드 Algorithm/92345.py at main · Junroot/Algorithm 풀이 모두가 이상적인 플레이를 했을 때 승자와 패자가 이미 결정되어있는 31게임이 생각났다. 31게임의 전략에서 힌트를 얻어서 구현을 했다. 31게임의 승자의 기본전략은 마지막으로 30, 26, 22, 18, …., 2를 말하는 것이다. 이를 dicision tree로 그려볼면 이렇게 된다. 여기서 빨간색 테두리는 승자가 항상 승리할 수 있는 전략이 있는 상태를 표시해둔 것이다. 이를 승자 노드에서 보면 다음으로 가는 노드에 항상 승리할 수 있는 상태인 것이 최소 하나만 있으면 된다....

날짜: 2022년 5월 25일 오후 6:31 오답: o 코드 Algorithm/92344.py at main · Junroot/Algorithm 풀이 잘못된 풀이 처음에 접근한 방법은 중복된 연산(덧셈, 뺄셈)을 피하기 위해서 배열의 표현을 자신의 왼쪽 또는 위쪽의 차이로 나타내려고 했다. 만약 자신의 왼쪽의 차이로 표현하면 아래 사진과 같다. 이렇게 하고 배열의 가로 길이가 더 길도록 transpose 하면 해결될 것이라고 생각했다. O(배열 세로 길이 * skill 길이)로 최악의 경우는 31 * 250000지만 시간초과가 발생했다. 맞는 풀이 결국 다른 사람 풀이를 확인했다....

날짜: 2022년 3월 19일 오전 1:59 코드 Algorithm/92343.py at main · Junroot/Algorithm 풀이 단순한 백트래킹 문제였다… 트리의 특성을 이용하는 건줄 알고 너무 어렵게 생각했다. 데이터의 개수가 적으면 단순 탐색도 가능하다는 것을 신경써야되는데 이 부분을 놓쳤다.

날짜: 2022년 5월 18일 오후 10:09 코드 Algorithm/92342.py at main · Junroot/Algorithm 풀이 두 가지 문제로 나눠서 생각할 수 있다. 어피치와 라이언의 점수 차이 계산하기 점수차이를 최대로 나도록 라이언이 쏘는 방법 구하기 어피치와 라이언 점수 차이를 계산하기 위해서 어피치가 점수를 얻은 영역에 더 많이 맞추면 점수를 2배로 얻는 것으로 구현을 했다. 어피치가 점수를 잃고 라이언이 점수를 얻는 것이 결국 라이언이 점수를 2배로 얻는 것과 같기 때문이다. 점수차이를 최대로 나는 경우를 찾기 위해서 dfs를 이용해서 모든 경우를 탐색하도록 구현했다....

날짜: 2022년 5월 16일 오후 2:40 코드 Algorithm/92341.py at main · Junroot/Algorithm 풀이 단순 구현 문제다. record 정보를 파싱해서 원하는 데이터 형태로 저장한다. 시간 정보는 0시 0분을 기준으로 지나간 시간을 분 단위로 저장했다. 차량 정보는 dictionary를 통해서 저장을 해두고 최종적으로 반환을 할 때는 정렬을 시켰다.

날짜: 2022년 5월 9일 오후 2:14 코드 Algorithm/92334.py at main · Junroot/Algorithm 풀이 자신을 신고한 유저들을 저장해서 개수를 세면된다.

편집 시간: 2022년 2월 9일 오후 6:18 코드 Algorithm/9095.py at main · Junroot/Algorithm 풀이 정수 n을 1, 2, 3의 합으로 나타낼 수 있는 경우의 수를 f(n)이라고 했을 때, f(n) = f(n - 1) + f(n - 2) + f(n -3) 라는 점화식이 만들어지는 것을 확인할 수 있으면 된다. 마지막에 더해지는 수가 1인 경우의 수는 f(n-1)이고, 2인 경우는 f(n-2), 3인 경우는 f(n-3)이기 때문이다.

편집 시간: 2022년 1월 31일 오후 5:52 코드 Algorithm/9012.py at main · Junroot/Algorithm 풀이 현재 열린 괄호의 개수를 깊이(depth)라고 하고, 문자열을 읽으면서 깊이가 음수가 되는 지점을 확인하면 된다. 또한, 문자열이 끝났을 때 깊이가 0으로 끝나는지 확인하면 된다.

실체화한 타입 파라미터(reified type parameter)를 사용하면 인라인 함수 호출에서 타입 인자로 쓰인 구체적인 타입을 실행 시점에 알 수 있다. 일반 클래스나 함수의 경우 타입 인자 정보가 실행 시점에 사라지기 때문에 구체적인 타입을 알 수 없다. 선언 지점 변성(declaration-site variance)을 사용하면 기저 타입은 같지만 타입 인자가 다른 두 제네릭 타입이 있을 때, 타입 인자의 상위/하위 타입 관계에 따라 두 제네릭 타입의 상위/하위 타입 관계가 어떻게 되는지 지정할 수 있다. 제네릭 타입 파라미터 제네릭 타입의 인스턴스를 만들려면 타입 파라미터를 구체적인 타입 인자로 치환해야 한다....

옵티마이저의 기능: 쿼리를 최적으로 실행하기 위해 각 테이블의 데이터가 어떤 분포로 저장돼 있는지 통계 정보를 참조하며, 그러한 기본 데이터를 비교해 최적의 실행 계획을 수립한다. EXPLAIN 명령으로 쿼리의 실행 계획을 확인할 수 있다. 개요 쿼리 실행 절차 SQL 파싱: 사용자로부터 요청된 SQL 문장을 잘게 쪼개서 MySQL 서버가 이해할 수 있는 수준으로 분리(파스 트리)한다. SQL 파서라는 모듈에서 처리한다. 최적화 및 실행 계획 수립: SQL의 파싱 트리를 확인하면서 어떤 테이블부터 읽거 어떤 인덱스를 이용해 테이블을 읽을지 선택한다....

외부 시스템에서 데이터를 읽거나 쓸 때 애플리케이션에서 필요한 형태로 변경하기 위해 어떻게 하든 데이터 처리가 필요할 수 있다. 스프링 통합(Spring Integration)은 Enterprise Integration Patterns라는 책에서 보여준 대부분의 통합 패턴을 사용할 수 있게 구현한 것이다. 각 통합 패턴은 하나의 컴포넌트로 구현되며, 이것을 통해서 파이프라인으로 메시지가 데이터를 운반한다. 간단한 통합 플로우 선언하기 애플리케이션은 통합 플로우를 통해서 외부 리소스나 애플리케이션 자체에 데이터를 수신 또는 전송할 수 있다. 스프링 통합은 통합 플로우를 생성할 수 있게 해준다....

누구도 일정을 짜지 않는 이유 일정을 짜는 작업 자체가 고통스럽다. 아무도 일정을 짜는 작업에 의미가 있다고 생각하지 않는다. 일정은 항상 틀린다는 선입견이 있다. 일정을 손쉽게 잘 짜는 방법 마이크로소프트 엑셀을 사용합시다 단순하게 만듭니다 각 기능은 과업 여러 개를 포함해야만 합니다 담당 프로그래머만이 제대로 일정을 짤 수 있습니다 과업을 세부적으로 나누십시오 과업을 세부적으로 쪼개다보면, 어떻게 진행할지 구체적인 단계를 생각하게 된다. 세부적으로 과업을 나누다보면 기능을 설계하지 않을 수 없게된다. 경험적인 규칙에 따르면, 각 과업은 적게는 2시간에서 많게는 16시간 이내에 처리할 수 있어야한다....

무선 랜의 구조 랜 케이블을 사용하지않고 컴퓨터를 연결하는 방식을 무선 랜이라고 한다. 무선 랜은 무선 액세스 포인트(Wireless Access Point, WAP)와 무선 클라이언트(컴퓨터나 스마트폰 등)로 구성된다. 우리가 흔히 말하는 무선 공유기에 무선 액세스 포인트 기능이 포함되어 있다. 무선 AP라고 부르기도 한다. 무선 클라이언트가 WAP와 통신하려면 무선 랜 칩과 무선 랜 어댑터가 필요하다. 최근 노트북의 경우 무선 랜 칩을 내장하고 있다. 무선 랜 어댑터는 USB 메모리 방식과 컴퓨터 카드 방식이 있다. 무선 랜을 연결하는 방식에는 2가지가 있다....

목의 가치 극대화하기 비관리 의존성에만 목을 사용하게끔 제한하는 것은 중요하지만, 이는 목의 가치를 극대화 하기 위한 첫 번째 단계일 뿐이다. 시스템 끝에서 상호 작용 검증하기 시스템 끝에 있는 비관리 의존성을 목킹하여 상호 작용을 검증하라. 어떤 라이브러리에 대한 래퍼 클래스가 있으면, 래퍼 클래스 내에 있는 라이브러리 클래스를 목으로 검증하라. 시스템의 끝에서 상호 작용을 확인하면 회귀 방지가 좋아질 뿐만 아니라 리팩터링 내성도 향상된다. 목을 스파이로 대체하기 스파이는 수동으로 작성하는 반면에 목은 목 프레임워크의 도움을 받아 생성한다는 것이 차이점이다....

요구 페이징 요구 페이징 개요 요구 페이징: 프로세스가 요구할 때 해당 페이지를 메모리로 가져오는 방식. 미리 가져오기: 앞으로 필요할 것이라고 예상되는 페이지를 미리 가져오는 방식. 요구 페이지 장점 메모리를 효율적으로 관리할 수 있다. 모든 페이지를 메모리로 가져올 필요가 없기 때문에 응답 속도가 빠르다. 페이지 테이블 엔트리의 구조 PTE에는 페이지 번호(주소 영역), 프레임 번호 뿐만 아니라, 플래그 비트가 존재한다. 플래그 비트에는 아래와 같은 비트들이 있다. 접근 비트(access bit): 페이지가 메모리에 올라온 후 사용한 적이 있는지 알려주는 비트....