archive 2022 posts

Author: Epikem

.github/workflows/update-blog.js.yml

@@ -15,6 +15,7 @@ jobs:
   build:
     env:
       # YEAR: $(date +%Y)
+      YEAR: 2022
       SOURCE_DIR: ../../TIL/
       TARGET_DIR: ./private/_posts/
 

TIL/2022-08-20.todo

@@ -0,0 +1,53 @@
+# log 2022-07-30
+
+--------------------------
+
+- [blog](#blog)
+- [study](#study)
+  - [clean architecture in rx](#clean-architecture-in-rx)
+- [tags](#tags)
+
+## blog
+
+## study
+
+### clean architecture in rx
+
+생각을 해보자.
+interactor와 controller에서 이미 검증을 하는데, data access에서 또 입력 검증을 할 필요가 있나?
+입력 검증보다는 수행을 하다가 발생하는 에러만 던져주면 될 것이다.
+
+다만, 여기서 수행하는건 입력 검증이 아니라 충돌 검증 등인데,
+여튼 rx 책을 보니 Try라는 오퍼레이터?를 만들어서 하는 방법도 나온다.
+근데 한 방법일 뿐이란 생각이 든다.
+
+그리고, clean architecture의 소리치는 아키텍처 내용에 따르면, 아키텍처만 봐도 어떤 애플리케이션인지 알 수 있어야 한다는데,
+현재의 책의 구조대로면, 의존 관계에 따라 컨트롤러를 나눌 것이고..
+궁금한 것은, 그 컨트롤러들도 서로 분리되어야 하는가? 서로 참조가 있다면? 같은 계층이니 바로 가져와서 써야 할 것이므로 같은 컴포넌트이고, 따라서 분리되는 것이 아니다.
+그렇다면 결국 아키텍처는 컴포넌트별로 interactors, entities, data access interfaces 등으로 나뉠 것이다.
+근데 그렇게 되면 그게 소리치는 아키텍처 아닌가? '클린 아키텍처 책의 방식대로 된 아키텍처다'라고 외칠 뿐 아닌가?
+
+그것보다 실질적이고 중요한 것은 로직을 주로 어디에 어떻게 두어야 하는가다.
+사용자를 추가하려는데, 아이디 충돌이 나지 않아야 한다는 것은, 비즈니스 로직의 문제인가, 저장 계층의 문제인가?
+내 생각에, 실질적으론 사용자를 id에 따라 검색하는 것이 비즈니스 요구사항은 아닐 것 같다. 다만 소프트웨어적 편리함 등의 문제로 id를 사용할 뿐.
+여튼 사용자의 id 기반 조회/변경/삭제 등이 비즈니스 로직이라 친다면 interactor에서 검사를 해야 할 것이고, 데이터 저장 계층만의 문제라면 저장 계층에서 해야 할 것 같다.
+그런데, 비즈니스 로직에서 검사했다면, 더 이상 아무런 검사 없이 data access 구현체에서 저장을 하도록 해도 괜찮을까?
+
+
+
+
+가상 스케줄러로 대기 없이 검사하는것도 흥미롭다.
+
+
+
+
+## tags
+- blog
+- study
+- clean-architecture
+- rxjs
+- typescript
+
+--------------------------
+
+

TIL/2022-08-21.todo

@@ -0,0 +1,197 @@
+# log 2022-08-09
+
+--------------------------
+
+- [blog](#blog)
+- [study](#study)
+  - [leet study](#leet-study)
+- [tags](#tags)
+
+## blog
+
+## study
+
+### leet study
+
+https://leetcode.com/problems/search-in-rotated-sorted-array/
+
+문제 이해가 잘 안된다.
+[0,1,2,4,5,6,7]
+
+rotated at pivot index 3 and become [4,5,6,7,0,1,2].
+
+아 잠만, 그냥 한번 읽으면 되지 않나 했는데, 시간복잡도가 O(lgN)이어야 한다고 한다.
+그러려면 한번 쭉 읽는것조차 허용되지 않는다.
+
+일단, 이분탐색이든 값 이용이든 해야 한다.
+
+그런데, 이분탐색하려면 정렬되어 있어야 하는데, 웬만큼 정렬되어 있긴한데 피봇이 가운데 있어서 애매하다.
+이 수열을 두 번 붙이면 가운데에 정렬된 원본 수열이 있겠지만, 어디부터 시작이고 끝인지 찾기가 애매하다.
+
+값-인덱스 기법은 어떨까
+
+[4,5,6,7,0,1,2] [4,5,6,7,0,1,2]
+
+삼분탐색을 써야 하나 싶기도 한데..
+엣지케이스 처리하기 애매할듯
+
+[0,1,2,3,4,5] [0,1,2,3,4,5]
+[5,0,1,2,3,4] [5,0,1,2,3,4]
+
+1 <= nums.length <= 5000
+-10^4 <= nums[i] <= 10^4
+
+딱히 값을 이용해서 더 빠르게 찾을 방법이 생각나지 않는데, 값-인덱스 기법은 대체로 비교보다는 동치연산에 쓰이므로..
+
+[4,5,6,7,0,1,2]
+
+최소나 최대값이라도 알면 ..
+지금 문제는, 이분탐색을 해야 하는데 정렬이 되어있지 않다는 것.
+
+[4,5,6,7,8,0,1,2,3]
+
+이런 경우 1을 찾으라 하면?
+
+1. 큰 수인 8을 먼저 본 경우
+더 작은 수인 1을 찾으려 계속 왼쪽으로 가다가 못 찾고 끝난다.
+2. 작은 수인 0을 먼저 본 경우
+오른쪽 구간에서 성공적으로 1을 찾을 것이다.
+
+그렇지만 이것은 pivot을 기준으로 양 옆을 찾은 덕분이고, 7과 8로 탐색을 시작한다면 둘 다 실패하게 된다.
+
+그럼 어떻게 해야 하나?
+1. pivot을 일단 찾는 방법:
+- 왼쪽 수가 오른쪽 수보다 큰 것을 범위를 줄여가며 찾는다.
+회전이 되어있다면 오른쪽 끝 수가 왼쪽 끝 수보다 작다.
+
+2. 양 끝에서 다른 탐색을 하는 방법:
+
+아, 지금 생각해보니 일단 target이 왼쪽 끝 수보다 크다면 그 쪽에 있을거고,
+아니라면 오른쪽 파트에 있을 것이다.
+
+증가하는 이분 탐색:
+
+- target 찾으면 종료
+- 오른쪽으로 갔는데 숫자 감소하면 왼쪽 탐색
+- 왼쪽으로 갔는데 target보다 작으면 오른쪽 탐색
+- 오른쪽으로 갔는데 target보다 크면 왼쪽 탐색
+
+감소하는 이분 탐색 
+
+- target 찾으면 종료
+- 왼쪽으로 갔는데 숫자 증가하면 오른쪽 탐색
+- 왼쪽으로 갔는데 target보다 작으면 오른쪽 탐색
+- 오른쪽으로 갔는데 target보다 크면 왼쪽 탐색
+
+7트만에 성공..
+
+도무지 이분탐색의 구간 엣지처리가 익숙해지질 않는다..
+
+<details><summary markdown="span">py3 solution</summary>
+
+```py3
+
+def search(nums: List[int], target: int) -> int:
+    import math
+    first = nums[0]
+    last = nums[-1]
+    cnt = len(nums)
+
+    if target >= nums[0]:
+        le = 0
+        ri = len(nums)
+        prev = -99999
+        while (le <= ri):
+            mid = math.floor((le + ri) / 2)
+            if (mid >= cnt):
+                return -1
+            cur = nums[mid]
+            print('1le',le,'ri',ri,'mid',mid, 'cur',cur)
+            if (cur == target):
+                return mid
+            if (cur < first):
+                ri = mid
+            elif (cur > target):
+                ri = mid
+            elif (cur < target):
+                le = mid + 1
+            if (mid == prev):
+                return -1
+            prev = mid
+        return le 
+
+    le = -1
+    ri = len(nums) - 1
+    prev = -99999
+    while (le <= ri):
+        mid = math.ceil((le + ri) / 2)
+        cur = nums[mid]
+        print('2le',le,'ri',ri,'mid',mid, 'cur',cur)
+        if (cur == target):
+            return mid
+        if (cur > last):
+            le = mid
+        elif (cur > target):
+            ri = mid - 1
+        elif (cur < target):
+            le = mid
+        if (mid == prev):
+            return -1
+        prev = mid
+    return le
+
+```
+
+</details>
+
+
+```py
+
+class Solution:
+    def search(self, nums: List[int], target: int) -> int:
+        if not nums:
+            return -1
+        l = len(nums)
+        start = 0 # 안쓰는 변수
+        end = l - 1 # 안쓰는 변수
+        left = 0
+        right = l - 1
+        while left + 1 < right:
+            mid = (right - left) // 2 + left # 그냥 분수로 계산하면 (le + ri) / 2와 같지만, 정수 연산이라 차이가 있을 듯.
+            if nums[mid] == target:
+                return mid
+            elif nums[mid] > nums[right]: # mid가 right보다 크므로, mid~right 사이에 회전 존재
+                if nums[mid] > target and target >= nums[left]: # left~mid 사이에 타깃 존재
+                    right = mid # left~mid 구간을 새 구간으로 설정
+                else:
+                    left = mid # mid~right 사이에 타깃 존재, mid~right 구간을 새 구간으로 설정
+            elif nums[mid] < nums[right] and nums[mid] > nums[left]: # mid가 right보다 작고, left보다는 크므로 구간 내 회전이 없음.
+                if nums[mid] < target: # mid가 타깃보다 작으므로, mid 이후 구간 검색
+                    left = mid
+                else: # mid가 타깃보다 크거나 같으므로, mid 이전 구간 검색
+                    right = mid
+            else: # 그 외. left~mid 사이에 회전 존재
+                if nums[mid] < target and target <= nums[right]: # mid가 타깃보다 작고, 타깃이 right보다 작음.
+                    left = mid # mid 이후 구간 검색
+                else:
+                    right = mid # mid 이전 구간 검색
+
+
+
+        if nums[left] == target:
+            return left
+        if nums[right] == target:
+            return right
+        
+        return -1
+```
+
+## tags
+- blog
+- study
+- sport
+- leet
+
+--------------------------
+
+

TIL/2022/2022-07-30.md

@@ -10,11 +10,23 @@
 ## blog
 
 aws workmail 사용해서 개인 도메인 이메일 설정완료.
-좀 비싸긴 한데.. 귀찮으니 일단.
+계정당 4천원이라 좀 비싸긴 한데.. 다행히 여러 alias들을 한 계정으로 몰아넣을 수 있어서 쓸만할듯.
+귀찮으니 일단..
+
 
 추후 git secret 설정 필요
 문제는, m1 mac에서 또 커밋이 안된다.
 
+```
+[2022-09-07T14:18:48.640Z] error: gpg failed to sign the data
+fatal: failed to write commit object
+```
+
+gpg indicator가 뜨면서 비번 해제 해야 커밋이 될 텐데, 그게 아예 안 뜬다.
+만들 때 뭔가 잘못 만들었나?
+
+
+
 ## study
 
 ### solve cf 158b

TIL/2022/2022-08-09.md

@@ -0,0 +1,23 @@
+# log 2022-09-24
+
+--------------------------
+
+- [blog](#blog)
+- [study](#study)
+- [job](#job)
+- [tags](#tags)
+
+## blog
+
+## study
+
+
+## job
+
+
+## tags
+- blog
+
+--------------------------
+
+