DeFacto-Standard IT

Spring Boot 2.4 기준 - application.properties wait.for-time=1s - MainApplication @SpringBootApplication @ConfigurationPropertiesScan // ConfigurationProperties를 스캔하도록 설정. Since 2.2.0 public class MainApplication { public static void main(String[] args) { SpringApplication.run(MainApplication.class, args); } } - WaitProperties properties를 읽어서 사용하는 클래스 @ConfigurationProperties("wait") @ConstructorBi..

AApplication.kt로 파일명을 지정하면 클래스 파일이 아니라 텍스트 파일로 인식이 되고, AApplications.kt로 파일명을 지정하면 클래스 파일로 인식이 되는 현상 발생 Preference - Edior - File Types - Text 에 AApplication.kt 가 등록되어 있음. 해당 항목 제외시킨 후 정상 작동 확인 참고: https://stackoverflow.com/questions/15915202/intellij-not-recognizing-a-particular-file-correctly-instead-its-stuck-as-a-tex

멀티 스레드 프로그래밍 환경에서는 멀티 스레드에 대한 실행 순서를 제어하는 것이 중요하다. OS는 멀티 스레드에 대한 실행한 순서를 보장하지 않는다. 따라서 운이 좋으면(?) 맨 마지막에 호출된 스레드가 맨 먼저 실행될 수도 있고, 운이 나쁘면(?) 맨 처음에 호출된 스레드가 맨 나중에 실행될 수도 있다. 물론 멀티 스레드를 제어하지 않는 경우도 있지만, 앞단에서 구한 결과를 가지고 뒷단에서 다시 재처리를 하는 경우라던가 할 때, 앞단의 작업이 끝나기도 전의 뒷단의 작업이 실행된다면 제대로 된 값을 구할 수 없거나 에러가 날 것이다. 먼저 실행 순서를 제어를 위해 커스텀 스레드를 정의하자. public class CustomThread implements Runnable { @Override public..

너비 우선 탐색 알고리즘 (BFS, Breadth First Search) 트리를 조회할 때, 너비를 기반하여 우선적으로 조회한다. 하나의 노드에는 여러 개의 노드가 연결되어 있는데, 특정 노드와 근접한 노드부터 검사한다. 트리에는 깊이라는 개념이 있다. 0번 노드는 깊이가 1이며, 1, 2번 노드는 깊이가 2이다. 그 밑으로 3, 4, 5, 6번 노드는 깊이가 3이고, 그 이후는 1씩 추가된다. 너비 우선 탐색(BFS)는 깊이 우선 탐색(DFS)과 다르게, 루트 노드에 인접한 노드를 먼저 모두 검사한 후, 그 다음 서브 노드로 옮겨서 그 서브 노드에 인접한 모든 노드를 검사하는 방식으로 동작한다. BFS의 구현은 DFS에서 사용했던 Recursive Call 만을 사용해서는 구현하기 힘들다. Recur..

깊이 우선 탐색 알고리즘(DFS, Depth First Search) 트리를 조회할 때, 깊이를 기반하여 우선적으로 조회한다. 하나의 노드에는 여러 개의 노드가 연결되어 있는데, 특정 노드의 한쪽 방향의 끝까지 먼저 검색한 후 다른 방향의 노드를 검사한다. 구현은 Recursive Call 혹은 Stack을 사용한다. 위 그림에서 0번 노드시작으로, 왼쪽 노드부터 내려가면서 1. 자신 검사 2. 왼쪽 노드 검사 3. 오른쪽 노드 검사 를 반복하게 된다. 이 때, 왼쪽 또는 오른쪽의 서브노드 검사 중 서브노드의 왼쪽, 오른쪽 서브노드가 또 있으면 위 과정을 계속해서 반복하게 된다. 트리는 배열로도 표현할 수 있지만, LinkedList로 표현하는 것이 일반적이다. 각 노드는 left, right라는 서브 ..

분할 정복 알고리즘의 일부 탐색법이다. 검색해야 할 대상(arr)을 절반씩 잘라서, 찾으려는 숫자(target)의 범위를 포함하는 서브 대상에서 다시 똑같은 방법으로 찾는다. 단, 절반으로 잘라서 찾는 분할정복법의 특정 상 속도는 굉장히 빠르지만, 배열은 정렬이 되어 있어야 한다는 제약이 따른다. [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11] 이라는 배열이 있고, 여기서 8을 찾는다고 가정해보자. left는 찾으려는 현재 배열의 가장 작은 값(가장 왼쪽 값) right는 찾으려는 현재 배열의 가장 큰 값(가장 오른쪽 값) mid는 찾으려는 현재 배열의 중간값 (가장 가운데 값) 을 뜻한다. - 1차 계산 [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11] 현재 배열에서 le..

- 문제 다음 배열이 있다고 가정해보자. [-2, 1, -3, 4, -1, 2, 1, -5, 4] 이 때, 배열 내부의 연속된 서브 배열 중 합이 가장 큰 경우를 리턴 예를 들어, [4, -1, 2, 1]의 합은 6으로 서브 배열 중 합이 가장 크다. - 풀이 우선 for문을 1자리 중에서 최대값을 찾고, 2자리 중에서 내부 for문을 돌면서 찾으면 성능이 나오지 않는다. 여기서 카데인 알고리즘을 적용하면 배열을 한 번만 순회하여 O(n)의 시간복잡도로 해결할 수 있다. 일반적으로 배열을 순회하면서 1. 1자리의 합을 모두 구해서 최대값을 구함 2. 2자리의 합을 모두 구해서 최대값을 구함 ... n. n자리의 합을 모두 구해서 최대값을 구함 등과 같이 생각했다면, 이 문제는 정답은 나올지언정 성능은 나..

- 개념 계산한 결과가 이후에 또 다시 필요할 경우, 재계산하지 않고 저장해놨다가 다음 계산에 재사용하는 알고리즘. - 대표적인 문제 LeetCode - 53. Maximum Subarray

- Summary이전 글(https://defacto-standard.tistory.com/796)에서 jackson-databind를 사용한 Polymorphic Serialize / Deserialize를 알아봤다. 이번에는 단순히 인터페이스 - 구체클래스의 관계로 구성되는 2depth Polymorphic Serialize / Deserialize가 아니라,중간에 한 계층이 더 들어간 3depth Polymorphic Serialize / Deserialize를 살펴보자. 2depth에서는 jackson-databind에서 제공하는 매핑 메타 어노테이션을 사용해ObjectMapper만을 한 번 래핑하여 특별한 구현 없이 어노테이션 만으로 비교적 쉽게 구현할 수 있었다. 결론적으로, 3depth 부터..

- Summary자바에서 직렬화(Serialization)란, Object를 네트워크나 스트림으로 저장할 수 있는 String 으로 변환하는 것을 의미한다. 이러한 스트림통신에서는 객체 자체를 전송할 방법이 없다. 웹에서 이미지를 보여주는 것을 예로 들어보자. 이미지가 포함된 페이지를 클라이언트가 HTTP Request를 보내면,웹서버에서는 등과 같이 String형태로 HTTP Response에 담아서 보낸다. 실제로, HTTP 헤더나 바디를 브라우저의 개발자 도구를 사용해서 까보면 전부 스트링 형태로 되어있다. 브라우저에서는 해당 HTML 코드를 해석하여 src에 해당하는 url에 존재하는 이미지를 바이트코드로 읽어들인 후,브라우저가 그림으로 보여주는 것이지, 이미지 자체 정보를 받는 것이 아니다. 이..