강아지의 코딩공부

postgresql trunc 함수를 알아봅시다.

코딩강아지 — Tue, 27 Jun 2023 23:58:58 +0900

postgresql에서 trunc 함수는 무엇일까요? 0 이상의 double형에서는 소수점을 버리기 위해, 미만인 경우 올림 처리를 하기 위해 쓰게 됩니다. 수학적으로 즉 0 이상에서는 floor와, 미만에서는 ceil과 동일하다고 할 수 있어요.

trunc(-1.23, 1)을 보겠습니다. 소수점 1째 자리까지 나타냅니다. trunc한 결과를요. -1.23은 0보다는 작으므로 ceil을 하게 됩니다. -1.3은 -1.23보다는 작고, -1.2는 -1.23보다는 크거나 같습니다. 따라서, -1.2가 출력됩니다.

실행 결과는 위와 같습니다. trunc의 2번째 인자에 아무것도 주지 않으면 0보다 크거나 같은 경우 floor를, 작은 경우 ceiling을 하게 되는데요. 아래 예제를 보겠습니다.

select trunc(1.2)를 보겠습니다. floor를 하니까 1.2보다 작거나 같은 정수 중 제일 큰 것을 찾아야 합니다. 1인가요?

따라서 1이 출력됩니다.

저는 이 함수를 random과 많이 쓰는 편입니다. 아래 예제를 보겠습니다.

이 예제는 generate_series를 이용해서, trunc(random() * 11)을 한 결과를 10만개를 뽑은 결과를 가지고 min값과 max값을 집계해 버립니다. 결과를 보겠습니다.

0과 10이 나오네요. 만약에 0보다 크고 10보다 작은 수를 랜덤하게 n회 뽑는 것은 generate_series와 random, trunc를 이용해서 가능하다는 이야기입니다. 한 가지 조심해야 할 점은 trunc의 경우 double precision이 들어가게 되면, 결과값으로 double precision이 나온다는 점입니다.

pg_typeof 함수로 trunc(random()*10)의 type이 어떤 것인지 출력해 보겠습니다.

double precision이 뜨네요. 따라서, 정수로 처리해야 한다면 뒤에 ::integer를 붙여서, 형을 변환해야 할 필요가 있습니다. 여기서 한 가지 질문. 그냥 random() * 10의 결과에 ::integer를 붙여도 되지 않나요? 이런 것을 검증하기 가장 쉬운 방법은 극단적인 케이스를 넣어보는 것입니다. 10.5와 같은 경계값을 넣어봅시다.

select 10.5::integer, trunc(10.5)::integer 이 두 값을 비교해 보겠습니다.

그랬더니 전자는 11이, 후자는 double precision 10이 나왔습니다. 고로 0보다 크거나 같은 경우, 정수값만 취하고 싶다. 그러면, trunc, floor 등을 이용해서 선처리를 해야 합니다. 그 이후에 정수형으로 바꿔야 한다. 그러면 ::integer나 ::bigint 등으로 형 변환 시켜버리면 됩니다.

파이썬 exception이 발생했을 때 retry 하는 로직을 작성해 봅시다.

코딩강아지 — Mon, 26 Jun 2023 23:53:39 +0900

exception이 발생하였을 때, 재시도를 r회 하는 로직은 생각보다 많이 쓰이게 됩니다. 어떻게 하는지 간단하게 알아보겠습니다.

예제를 하나 보겠습니다.

위 예제는 t = 1/0을 10번 재시도 하는 예제입니다. 보시면, t = 1 / 0 부분에서 계속 ZeroDivisionError가 뜨게 됩니다. 이 때, r이 retry보다 작으면 continue를 하고, 그렇지 않으면 raise를 하게끔 하였습니다. retry는 재시도 횟수인데요. 1부터 retry회까지 카운트가 됩니다. 고로, r이 retry보다 작다면 continue문을 타고, retry번 이상 재시도를 했다면 raise, 그러니까 예외를 발생시켜버리게 됩니다.

10번 재시도를 하고, ZeroDivisionError가 뜨게 됩니다. 저 코드 제대로 동작할까요? 10번 재시도를 해도 exception이 계속 발생하면 raise를 한다. 문제 없어 보입니다. 그런데 아래 프로그램을 실행시켜 보겠습니다.

이번에는 t = 1 / 2를 수행하였습니다. 1번만에 성공하였습니다. 그런데, 이거 retry가 몇 개나 찍힐까요?

성공하였음에도 10번이 찍히게 됩니다. 1번만에 성공하면 재시도를 하지 말아야 하는데 그렇지 못한 이유는 for loop로 계속 돌아버리고 있기 때문입니다. 성공했다면, return을 하던지, 아니면 break를 걸어야 합니다.

필요한 부분만 도식화 해서 그려보겠습니다. 10번동안 재시도 하는 로직이 바깥 for loop로 돌고 있어요. 그리고, 예외가 걸렸을 때, 재시도 횟수가 10회 이하이면 continue를 한다고 되어 있어요. 이는 for loop의 전체를 건너 뛴다는 의미입니다. 고로, 이 때에는 즉시 변수 retry가 하나 증가할 수 밖에 없습니다.

그런데, except ~ 문에 걸리지 않는 경우에도 for loop 안에 있어요.

이 경우 빨간색 화살표를 따라가게 됩니다. 핵심은 재시도 loop를 탄다는 점입니다. 언제까지? retry가 10이 넘어갈 때 까지 loop를 돌아버리게 됩니다.

어떻게 하면 좋을까요? 예외에 걸리지 않은 경우에 바로 break나 return을 걸어버리면 됩니다. 아래 코드를 볼게요.

except ~ 절에서 재시도 횟수가 retry 이하라면 contine를 걸고, 그 이상이라면 raise합니다. 예외에 걸리지 않으면 12번째 줄로 올 겁니다. 이 때에는 for loop 자체를 빠져나가야 합니다. 따라서 break를 걸어야 합니다. 이렇게 하면 어떻게 될까요? t = 1/2가 성공했기 때문에, 1번만 시도하게 됩니다.

retry 1만 출력되게 됩니다.

t = 1/0을 10번 시도하는 것은 잘 될까요?

당연하게도 잘 됨을 볼 수 있습니다. 왜냐하면, 계속 excep ZeroDivisionError에 걸리기 때문입니다.

이를 도식화 시키면 위와 같습니다. 예외에 걸리지 않으면 성공했기 때문에 더 이상 retry를 할 이유가 없습니다. 따라서, break 문으로 재시도 loop를 빠져나오면 되는 것입니다.

java right shift operator >>와 >>>에 대해 알아봅시다.

코딩강아지 — Sat, 24 Jun 2023 23:58:52 +0900

java의 bit 연산자 중에 >>와 >>> 연산자가 있습니다. 이 둘의 차이에 대해 간단하게 알아보겠습니다.

먼저, 위에 2개는 -2 >> 1과 -2 >>> 1의 값을 출력합니다. 아래 2개는 2 >> 1과 2 >>> 1을 출력합니다.

출력 결과를 봅시다. -1, 2147483647이 나오고, 밑에 2개는 1, 1이 나옵니다. 이게 어떻게 된 것일까요?

먼저 -2의 2의 보수 표현법으로 표기해 봅시다.

2를 2진법으로 표현하면 위 그림과 같습니다. 여기서 비트가 0인 것은 1로 바꾸고, 1인 것은 0으로 바꿔보겠습니다.

그러면 1...1101이 됩니다. 여기서 1을 더해보겠습니다.

그러면 11..110이 됩니다. 여기에서, 부호를 결정하는 비트는 1로 표시했습니다. t가 -2인 경우, 표현 방식은 위와 같습니다. 이제, -2 >> 1과 -2 >>> 1의 차이를 알아봅시다. 먼저, >> 연산자는 부호도 그대로 가지고 옵니다. 맨 처음의 부호에 따라서 채워지는 비트가 정해진다는 것입니다.

일단 모든 비트를 오른쪽으로 하나씩 이동시켜 보겠습니다. 그러면 위 그림과 같이 되겠네요. t >> 1은 부호 비트에 따라서 좌측에 채워지는 비트가 결정됩니다. 위의 경우는 부호 비트가 1이므로, 1이 채워지게 됩니다.

그러면 요래 채워지겠군요. 반면에 >>> 1은 아래와 같이 동작합니다.

채워지는 비트가 0이 됩니다. 앞에 붙은 게 1이냐 0이냐 상관 없이요. 그리고 32bit 자료형에서 01...1 패턴은 2147483647입니다. 맨 앞의 부호 비트에 따라서 앞에 붙어 있는 bit가 달라지는 >> 와는 다른 점이기도 합니다. t=2인 경우 t >> 1과 t >>> 1의 결과는 같을까요?

먼저 t >> 1입니다. 0...010이 오른쪽으로 1칸씩 이동합니다. 다음에, 부호를 판정하는 비트가 0이였기 때문에 나머지 부분은 0으로 채워집니다. t >>> 1은 어떨까요? 앞에 부호가 1이던 0이던 무조건 0으로 채워지기 때문에 결과가 같게 됩니다.

이제 이 경우는 어떨까요?

-5는 111...1011 패턴으로 채워집니다. 이걸 2칸 오른쪽으로 옮기면 위 그림과 같이 됩니다. t >> 2의 경우에는 어떻게 처리될까요? 맨 앞의 부호 비트가 1이였기 때문에, 앞에 2개가 1로 채워집니다.

11...10 패턴이네요. 0을 1로, 1을 0으로 바꾼 다음에 1을 더해 봅시다. 그러면 00...01에 1을 더했으므로, 00..010이 됩니다. 2가 되네요. 앞의 부호 비트가 1이므로 -2가 되겠습니다.

반면 t >>> 2는 앞에 2개를 0으로 채워버립니다. 앞의 부호 비트가 1이여도요. 00111...10은 2^30-2입니다. 1073741822가 됩니다.

결과를 보면 위와 같습니다.

sqlalchemy like 연산의 %와 _를 escaping 처리해 주는 startswith, endswith, contains를 알아봅시다.

코딩강아지 — Fri, 23 Jun 2023 23:42:24 +0900

안녕하세요. 이번 시간에는 sqlalchemy에서 like 연산자를 쓰는 방법을 알아보겠습니다. 하나 조심해야 할 것은, 당연하게도 유저의 입력값을 믿으면 안 된다인데요. 이게 무슨 소리일까 싶습니다. like의 경우 %와 _ 등으로 인해 의도치 않은 결과가 나올 수 있습니다. 입력값 필터링을 하지 않거나 escaping을 하지 않은 경우 문제가 발생할 수도 있다는 의미입니다.

먼저 실습에 사용할 데이터입니다. 테이블 A에는 title이 aa, ba, _a, %a인 것이 있습니다.

그리고 models.py에 정의된 모델 A에 대한 클래스입니다.

저는 like 연산자를 썼습니다. Query parameter로 들어오는 keyword에 대해, 접두어가 keyword인 title을 찾습니다. 무엇이 문제일까요? 정확히 말하면 f"{keyword}%"가 문제입니다. 입력값 필터링을 하지 않고 사용자의 입력을 믿어버리면 절대로 안 됩니다. keyword가 특정한 문자가 들어오지 않는다면 의도대로 동작이 할 겁니다. 예를 들어, keyword에 a를 넣어보겠습니다.

a로 시작하는 "aa"만 나옵니다.

문제는 _a인데요. 저 경우 where title like '_a%'로 rendering이 되어 버립니다. like에서 _는 어떠한 character와도 매칭됩니다. 따라서, "aa", "ba", "_a", "%a" 이렇게 4개가 매치되게 됩니다. 당연하게도 %a를 넣어도 의도치 못한 결과가 나오게 됩니다. 왜 그럴까요? 2가지 이유가 있습니다. 유저 입력을 그대로 믿어버린 것. 그리고 특정한 문자가 escaping이 되지 않은 것입니다.

어떻게 해야 할까요? 접두 검색의 경우, startswith를 쓰면 됩니다. 그리고 autoescape를 True로 설정하면 됩니다.

이 프로그램을 보겠습니다. A.title.startswith(keyword, autoescape=True)라고 되어 있네요.

그러면 _a로 시작하는 결과만 나옵니다. 이는 _가 어떠한 하나의 캐릭터와 매치되는 특수 문자가 아니라, 다른 것으로 랜더링 되어 버렸기 때문입니다. 그리고 %와 _가 나오는 곳에 앞에 /가 붙습니다. 즉, %와 _가 escaping 됩니다. 이는 문서에도 언급되어 있는 부분입니다.

쿼리를 출력해 보겠습니다. 그러면 Like :title_1 || '%' escape '/'가 나오네요. 사실 title에 그대로 %가 남아 있었으면 _a만 출력되지않았을 겁니다. 이 말은, 문서에서 언급한 대로 특정한 문자들이 LIKE 쿼리 안에서 escape가 된 상태로 render가 된다는 의미입니다. 접미 검사는 어떻게 하면 될까요?

비슷한 원리로, endswith를 쓰면 됩니다. autoescape를 True로 startswith와 마찬가지로, LIKE 안에 들어가는 param 부분에 포함되어 있는 %와 _를 escaping 하게 됩니다.

어떠한 string이 포함되었는지 검사하기 위해서는 contains를 쓰면 됩니다.

파이썬 dataclass frozen을 이용하여 불변 객체를 흉내내 봅시다.

코딩강아지 — Tue, 20 Jun 2023 23:57:29 +0900

불변 객체는 생각보다 중요합니다. 예를 들자면, 해시에서 키를 넣을 때, 변할 수 있는 객체면 곤란해 질 수 있습니다. 왜냐하면 객체의 내용이 변하면 hash값이 변하기 때문입니다. 하지만, hash에서 탐색하기 시작하는 위치는 안 바뀌기 때문에 (재해싱을 하지 않는 이상) 이상하게 동작하게 됩니다.

python에서는 immutable을 흉내낼 수 있는 것이 있는데요. dataclasses의 frozen을 True로 설정하면 가능합니다. 간단하게 알아보겠습니다.

3.7부터 추가된 dataclass를 이용해서, immutable을 흉내낼 수 있다고 하였습니다. 잠깐. immutable의 대표적인 것은 tuple이 있습니다. 반면, mutable은 list가 있습니다. list는 append 등으로 원소를 뒤에 추가할 수 있기 때문입니다. 위 문서에서 frozen이 참일 때 어떤 일이 일어나는지를 설명해 주고 있어요. instance가 생성된 후에 field에 값을 대입할 수 없다.

불변 흉내를 낼 수 있다는 소리입니다. 예제를 보겠습니다.

class Obj가 있는데요. frozen이 True로 되어 있어요. 고로, x와 y는 생성이 되고 난 후에는 아예 초기화를 할 수 없습니다. 어떻게 초기화를 시킬까요?

o1 = Obj(x=3, y=3) 요래 넘겨줍니다. 그러면 생성이 되는 단계에서 x에 3을 집어넣고, y에 3을 집어넣습니다. 그리고 끝납니다. 그 이후에는 대입를 할 수 없습니다.

실행 결과는 요래 나오게 됩니다.

12번째 줄에 o1.x = 3이라고 입력했더니, 에러가 뜹니다. 왜? Obj object의 x가 읽기 전용이기 때문입니다. o1.x = 3를 실행했을 때에는, 이미 객체 o1이 생성 되고 난 후였습니다. 그렇기 때문에, o1.x에 assign을 하는 것 자체가 되지 않습니다.

그러면, __setattr__ 등으로 할 수 있지 않을까요? __setattr__은 속성에 값을 집어넣습니다.

실행을 시켜 보니, FrozenInstanceError가 나오게 됩니다. 이미 만들어진 객체의 필드에 다른 값을 assign 할 수 없다는 의미입니다.

조심해야 할 것은, 생성이 된 객체의 필드에 assign이 안 된다는 것입니다. 이 말은, field가 mutable인 경우에, field의 내부 값이 변경될 수도 있다는 것입니다.

z: list라고 되어 있습니다. 리스트는 아시다 시피 불변 객체가 아닙니다. o1을 생성하는 과정에서 z가 초기화 되었습니다. list 객체로요. 그런데, assign만 안 될 뿐이지, 생성된 객체에 append를 해서 상태를 변경시킬 수 있어요. o1.z.append("3"), o1.z.append("4")를 수행하는데요. o1.z가 불변 객체가 아니기 때문에, o1 안에 들어있는 list에 3과 4가 추가되게 됩니다.

실행 결과는 위와 같습니다.

python hash 함수에 대해 알아봅시다.

코딩강아지 — Mon, 19 Jun 2023 23:50:25 +0900

python에는 hash 함수가 있습니다. 무엇을 하는 함수일까요?

간단하게 hash(1)과 hash('str')을 입력해 보겠습니다.

그랬더니 1과 -34797.. 이 나옵니다. 객체의 hash값을 돌려주기 위해서 쓴다. 정도로 추정할 수 있습니다.

이제, Obj 하나를 정의해 보겠습니다. 생성자에 인자 x를 받습니다. 그러면 Obj의 필드 x에 x의 값을 넣습니다. 이제 Obj(1)의 해시값과, 다른 객체인 Obj(1)의 해시값을 비교해 보겠습니다.

다릅니다. 왜? __hash__가 재정의 되어 있지 않기 때문입니다. 파이썬에서는 dict, counter 등이 hash를 기반으로 동작하는데요. 키 값으로 custom한 객체를 넘겨줄 때 __hash__를 재정의 해야 할 겁니다. 이 __hash__ 안에 hash 함수를 쓸 거라는 예상을 할 수 있습니다.

예제를 하나 보겠습니다.

__eq__랑 __hash__랑 __str__을 재정의 해 주었습니다. __eq__를 정의하면 __hash__도 재정의를 해 주는 것이 국룰입니다. 특히 custom하게 정의한 class의 object를 해시 기반 자료 구조의 key 값으로 쓰려는 경우. 객체가 동등하더라도, hash값이 다르면 다른 hash값을 가지기 때문에, 탐색 시작 위치가 달라져 버릴 수 있기 때문입니다. Obj의 필드는 x 하나밖에 없기 때문에, hash(self.x)를 리턴했습니다만, 2개의 필드에 대해서 해시값을 생성하려는 경우 tuple 등을 생각해 보는 것이 좋습니다.

lt에 Obj(1), Obj(1)을 넣어두었습니다. 저는, 이 lt에 있는 것을 set으로 옮겼습니다. 실행 결과가 어떻게 나올까요? 일단 __eq__랑 __hash__를 재정의 했기 때문에, Obj(1)과 뒤에 있는 Obj(1)은 중복 처리가 됩니다.

따라서 Obj: 1만 출력이 됩니다. collection의 Counter도 마찬가지일까요?

c[Obj(1)] += 1 이런 식으로 작성해 주면, 키 Obj(1)의 개수가 하나 증가합니다. 결과는 Obj: 1 = 2, Obj: 2 = 1이 나오게 될 것인데요. Obj가 x 값만 같으면 동일하고, hash 값도 같기 때문입니다.

실행 결과가 제가 예상했던 것과 그대로 나왔네요.

여기서 질문. 이 경우에는 어떨까요? 사실 hash값이 같지만, 동등하지 않는 경우는 의외로 있습니다. 키 3과 5가 같은 hash 값을 가지지만, 동등하지 않은 것과 같은 이치인데요. __eq__가 정의되지 않았으므로, 필드 값이 1이더라도, 별개의 객체인 경우 동등하지 않습니다.

따라서, 위 코드의 경우 Obj(1), Obj(1), Obj(2)가 별개로 count가 됩니다. 한 마디로 hash가 제대로 동작하지 않는다는 것입니다.

실행 결과는 위와 같습니다. 키를 찾기 위한 base 위치는 같겠지만, 필드 x의 값이 같은 별개의 객체 a와 b는 다른 객체이므로, a만 존재하는 경우, b가 없다고 판단하게 됩니다.

fastapi celery로 간단하게 특정 시간마다 task가 실행되는 schedular를 만들어 봅시다.

코딩강아지 — Sat, 17 Jun 2023 23:57:45 +0900

fastapi에서 일정 주기로 뭔가를 실행시키는 방법이 없을까요? 예를 들어, 자정 12시마다 방문자 수를 초기화 한다던지, 통계 데이터를 수집해야 하는 경우가 있습니다. 이를 cron으로 돌려서 처리할 수도 있습니다만, 여간 귀찮은 것이 아닙니다. celery에는 worker 뿐만이 아니라, 스케쥴러를 등록해서 사용할 수도 있습니다. 간단하게 알아보겠습니다.

프로젝트 구조는 위와 같습니다. core의 celery 안에 있는 base.py로 들어가 보겠습니다.

코드를 보겠습니다. broker와 backend는 redis를 사용하였습니다. 고로 redis 주소를 적어주었습니다. 다음에, include에는 실행할 테스크가 있는 "app.sche.sche"를 적어주었습니다. 위 코드에서는 메세지를 전송하는 주체와 수신하는 주체를 중개해 주는 역할을 redis가 하게 됩니다.

다음에, celery_task의 conf의 beat_schedule에는 실행할 task에 대한 정보를 적어줍니다. app.sche.sche.sche_every_minute라는 테스크를 실행하는데요. "schedule"에 crontab()을 넣어줍니다. crontab에 아무 인자도 들어가지 않은 경우, 매 분마다 실행되게 됩니다.

매 분마다 실행시킬 task입니다. task는 "doai station"을 출력하는 것입니다. 여기까지 내용을 정리해 봅시다.

스케쥴러를 정의했는데요. 여기에 매 분마다 실행되는 sche_every_minute task를 등록해 줍니다. 이 task는 1분마다 어딘가로 전송이 될 겁니다

이제, worker에게 해당 task를 전송합니다.

매 분마다 요런 흐름으로 로직이 구성됩니다. 간단하게 테스트 해 보겠습니다.

이제 간단하게 명령어를 입력해서 테스트 해 보겠습니다. app.core.celery.base.celery_task에 실행시킬 task들이 있습니다. 뒤에 worker -B가 붙어 있습니다. 이는 embedded beat를 사용한다는 의미입니다. 간단하게 테스트 하기 위해 embed beat를 이용합시다.

1분마다 doai station이 출력되는 것을 볼 수 있어요. 다음 시간에 저 명령어에 대해서 조금 더 자세히 알아보도록 하겠습니다.

postgresql string_agg 함수 정렬과 중복 제거를 알아봅시다.

코딩강아지 — Fri, 16 Jun 2023 23:16:52 +0900

안녕하세요. 이번 시간에는 postgresql에서 쓰는 string_agg 함수에 대해 간단하게 알아보겠습니다. 그리고 정렬하는 것과 중복 제거하는 것도 같이 알아볼게요.

먼저, string_agg는 컬럼의 값들을 하나의 string으로 합쳐주는 역할을 합니다. 입력으로 들어오는 row의 속성들을 하나의 string으로 합칠 때 쓰입니다. 이게 무슨 말인가? 예제를 하나 보겠습니다.

temp_data를 with 절로 정의했어요. 속성 t의 값이 'a'인 것과, t의 값이 'b'인 것과, 'Z'인 것을 union한 결과를 temp_data로 정의했어요. 이제, temp_data에 있는 내용을 출력해 봅시다.

'c', 'b', 'Z', 'b'가 나옵니다. 이제 이것을 string_agg로 합쳐 보겠습니다.

temp_data의 t의 모든 값들을 합치는데요. 2번째 인자는 delimeter입니다. 구분자를 의미해요. 결과를 볼까요?

c-b-Z-b가 나옵니다. temp_data에는 레코드들의 속성 t가 'c', 'b', 'Z', 'b' 순으로 있었는데요. 이것이 aggreate가 되면서, 'c-b-Z-b'가 되어버린 것입니다.

이제, distinct와 order by를 알아봅시다. string_agg에서 input row가 들어올 때, 중복된 것들을 제외할 수도 있습니다. 그리고 우리가 원하는 대로 ordering 또한 할 수 있습니다. 간단하게 알아볼게요.

먼저 distinct입니다. 입력 row의 속성 t는 'c', 'b', 'Z', 'b'입니다. 여기서 'b'가 2번 나왔어요. 이것을 제거해서, 'b', 'c', 'Z'만 나오게 하고 싶어요. 그러면 어떻게 하면 되느냐. 그냥 1번째 인자에, distinct t를 써 주면 됩니다. 속성 t에 대해서 중복을 제거하겠다는 의미입니다. 결과가 어떻게 나오는지 보겠습니다.

b-c-Z가 나옵니다. 아까 중복 처리를 해 주지 않았을 때에는 c-b-Z-b가 나오던 것과 대조적이지요. 그런데 말이지요. 어떨 땐 c가 먼저 나오기도 하고 어떨 땐 b가 먼저 나오기도 해요. 이것은 order 순서가 없기 때문에 그러해요. 결과가 어떻게 나올지 모르지요. 이 경우, order by를 해서 ordering을 지정해 줄 수도 있습니다.

2번째 인자에 '-' order by t desc가 있습니다. 이는, 들어오는 row의 속성 t 값을 내림차순으로 정렬하라는 의미입니다. 대신에 앞에 중복을 제거하는 distinct가 없으니까, b가 2번 나오겠지요?

결과는 Z-c-b-b가 나옵니다. 이제 중복 제거와 정렬을 같이 적용해 봅시다.

string_agg(distinct t, '-' order by t desc) 요래 입력해 보겠습니다. 그러면 이건, 입력이 들어오는 row들의 속성 t에 대해서 중복을 제거해 주면서, t값에 대해 내림차순 정렬을 합니다. 그러면 Z-c-b가 나오게 됩니다.

Z-c-b가 잘 나왔음을 알 수 있습니다. 이걸 조금 더 응용한다면, 랜덤한 문자열을 뽑을 때도 유용하게 사용할 수 있습니다.

fastapi sub application에 대해 알아보고 app마다 다른 middleware를 적용해 봅시다.

코딩강아지 — Tue, 13 Jun 2023 23:55:03 +0900

fastapi에서는 application 안에 application을 넣을 수 있습니다. sub application이라고 칭하겠습니다. 이 sub application들을 mount를 하면, 각 어플리케이션 별로 미들웨어 등을 넣을 수 있어요. 분리를 한다? 예를 들어, health check 어플리케이션이랑, api 어플리케이션이랑 분리할 수 있습니다.

이 방법을 간단하게 알아볼 거에요.

먼저 패키지 구조부터 보겠습니다. 별 다른 것은 없고요. sub 패키지 안에 sub_app_1.py와 sub_app_2.py가 있는 구조에요.

먼저 main.py를 보겠습니다. app_1과 app_2를 import 하는데요. 하나는 /sub1에, 다른 하나는 /sub2에 mount 합니다. 여기까지 어렵지 않지요? 여기까지 그림으로 그려보겠습니다.

/sub1은 어플리케이션 인스턴스 app_1에 mapping이 되고, /sub2는 어플리케이션 인스턴스 app_2에 매핑됩니다. 이 어플리케이션 인스턴스에는 여러 가지 설정들을 할 수 있는데요. 대표적으로 get, post와 같이 api를 추가할 수도 있고, 미들웨어를 추가할 수도 있어요.

먼저, app_1을 봅시다. app_1 = FastAPI()라고 되어 있어요. 어플리케이션 인스턴스를 선언했어요. 이 app_1은 메인 어플리케이션 객체에 mount 되어 있어서, subapp이라고 할 수 있어요. 여기에는 어떤 설정이 있나요? app_1.get("/health") 정도만 있어요. get /health 정도만 추가로 있네요. 여기까지 그림으로 그려 보겠습니다.

그렇기 때문에, get /sub1/health로 접근하면 "ok"가 나오게 됩니다. 이제 sub2를 보겠습니다.

여기도 마찬가지로 어플리케이션 인스턴스를 생성하였어요. 다른 점이 하나 있다면, 미들웨어를 하나 추가했다는 것입니다. 뭔가 이상한 것을 추가한 것을 볼 수 있는데요. TrustedHostMiddleware입니다. allowed_hosts를 "localhost"로만 설정해 놓았음을 볼 수 있어요.

그러면 이것도 그림으로 그려볼게요.

요래 되었네요. 결국, app_1과 달리, app_2는 Trusted Host 미들웨어를 타게 됩니다. 여기까지 정리하면 sub app으로 어플리케이션을 분리해서 mount를 시켜 놓았습니다. 각 sub app별로 middleware를 설정하였기 때문에, 어떤 api endpoint에서는 미들웨어를 타고, 어떤 곳에서는 타지 않게 하려면 이 방법을 쓰는 방법도 나쁘지 않습니다.

이제, postman으로 호출을 한 번 해 보겠습니다.

먼저, http://127.0.0.1:8000/sub/health를 호출해 보겠습니다. /sub1에 mount된 app의 경우에는 아무런 Trusted Host 미들웨어가 걸려있지 않습니다. 고로, 응답은 아래와 같이 오게 됩니다.

200 OK가 잘 수행되었네요.

문제는 /sub2/health입니다. 127.0.0.1:8000의 경우 host가 127.0.0.1이였기 때문에, middleware에서 Invalid host header가 뜨면서, 400 에러를 떨구게 됩니다.

대신에 GET http://localhost:8000/sub2/health 요래 호출하면 이야기가 달라집니다. 이 때에는 host가 localhost로 잡힙니다.

이것은 허용 host 옵션에 있기 때문에, 200이 떨어지게 됩니다.

postgresql with 여러개 선언해서 사용하는 방법을 알아봅시다.

코딩강아지 — Mon, 12 Jun 2023 23:53:35 +0900

postgresql에서 with 절은 임시 결과를 정의할 때 유용하였습니다. 이걸 여러 개를 쓸 수 있을까요? 2023년 6월 1일부터 오늘까지 통계치를 뽑고 싶을 때 유용하게 쓰일 법한 예제를 보면서 간단하게 알아보겠습니다.

테이블 d에는 id, s, created 필드가 있습니다. s와 created는 각각 내용과 생성된 날을 의미합니다. 어떤 레코드들이 있는지 보기 위해, select * from d; 를 입력해 보았습니다.

그랬더니 요래 나오는군요. created의 맨 마지막 부분에 +0900이 되어 있는 것으로 보아, 서울 시간으로 되어 있는 것이 분명하군요. 이제 저는 날짜별로 몇 개의 레코드가 생성되었는지 집계하고 싶습니다. 어떻게 하면 될까요? 날짜별로 집계 하려면 group by 날짜를 하면 되겠습니다. date 함수가 이를 해결해 줍니다. 다음에, 갯수를 출력하는 것은 그냥 간단하게 count 함수로 해 주면 됩니다.

중요한 것은 어느 시간대로 할 것이냐인데요. 서울 시간대로 하겠습니다.

group by date(created at time zone 'Asia/Seoul')을 입력함으로써, 서울 시간 기준 날짜별로 몇 개씩이나 생성되었는지 집계합니다.

결과는 위와 같습니다. 이를 date_static라는 임시 결과로 내보낼 거에요.

이제, 2023년 6월 1일부터 오늘까지의 날짜를 뽑아 봅시다. postgres에는 generate_series 함수가 있어요. 위 쿼리로 2023년 6월 1일부터, 오늘 날짜인 6월 12일까지 뽑게 됩니다. temp_dd:date는 date로 형변환을 합니다.

실행 결과는 위와 같습니다. 이를 date_t라는 이름의 임시 결과로 내보낼 거에요.

딱 봐도 두 쿼리. 간단해 보이진 않습니다. with 절을 여러 개 선언하는 방법은 with name1 as (...), name2 as (...) 요래 선언하면 되는데요. , (콤마)로 구분하시면 됩니다. 13번째 줄까지 보겠습니다.

보시면 with date_static as q, date_t as q' 꼴로 되어 있어요. 이는 쿼리 q의 실행 결과는 date_static이라는 임시 결과로, 또 다른 쿼리 q'의 실행 결과는 date_t라는 임시 결과로 내보내겠다는 의미입니다. date_static은 dd와 cc가 있습니다. date_static의 dd는 날짜, 그리고 cc는 날짜별로 생성된 레코드 수를 의미해요. 당연하게도 이 임시로 선언된 date_static과 date_t는 ;가 끝나기 전까지입니다. 만약에 13번째 줄에서 ;를 선언해서 끝내버렸다고 합시다. 그 경우 그 다음에 이어지는 left outer join문에서 date_t와 date_static은 사용하지 못합니다.

다음 date_t의 dd는 2023년 6월 1일부터 오늘 날짜인 2023년 6월 12일을 의미합니다. 우리는 2023년 6월 1일부터 오늘 날짜까지 통계 데이터를 뽑아야 하는데, date_static에는 2023년 6월 1일 이후의 날짜가 없을 수도 있단 말이지요. 따라서, date_t와 date_static을 outer join 합니다.

그러면 요래 나오는데요. 2023년 6월 1일, 2023년 6월 2일 등은 우측 테이블인 date_static에 없었기 때문입니다. cc가 NULL일 때 0으로 카운트 되게 하기 위해서는 postgres에서는 colaesce를 사용하면 됩니다.

14번째 줄에 select date_t.dd, coalesce(date_static.cc, 0)으로 바꿔 봅시다.

그러면 위와 같이 변경됨을 확인할 수 있습니다.

fastapi pydantic 필드 단위로 동작하는 validator를 간단하게 알아봅시다

코딩강아지 — Fri, 9 Jun 2023 23:47:11 +0900

안녕하세요. 이번 시간에는 field 단위로 동작하는 validator에 대해 알아보겠습니다.

먼저 아래 프로그램을 보겠습니다.

x: int = Field(gt=5)라고 되어 있습니다. pydantic의 Field인데요. gt는 greater than의 약자입니다. 즉, 5보다 커야 된다는 조건이 있어야 합니다. 9번째 줄에는 custom validator를 작성하였는데요. "x"는 필드명을 의미합니다. 필드명 x에 대한 커스텀 벨리데이터 함수는 check_x를 의미해요.

1번째 인자는 cls, 2번째 인자는 v인데요. v는 실제로 check_x에 들어온 필드 x의 값을 의미합니다. 보통 이 v값을 검증해서, 조건에 맞지 않으면 ValueError를 떨어트리게 됩니다. pre=True라고 되어 있는데요. 어떻게 실행되는지 보겠습니다.

x에 -6을, y에 0을 넘겨주었습니다. 그러면, pre=True이므로 check_x가 실행됩니다. 들어온 v의 값이 10보다는 작았으므로, -v 값인 6이 리턴됩니다. 그 다음에 Field(ge=5) Validator로 넘어가는데요. 6은 5보다 크므로 참이 리턴됩니다.

post /res가 호출되면, 그대로 res_request.x와 res_request.y를 돌려주게 되는데요. validation을 하는 과정에서, res_request.x의 값에 -1이 곱해집니다.

결과는 x가 6, y가 0이 나오게 됩니다.

반대로 이 경우에는 어떨까요? Field(gt=5) 먼저 수행되게 됩니다.

다시 post /res에 요청을 요래 날려보겠습니다.

그러면 아까와 다르게 not_gt 에러가 뜨면서 422가 떨어짐을 알 수 있어요. int는 gt, ge, lt, le 등을 상당히 많이 쓰니 알아두면 좋습니다.

문자열의 경우도 검증을 많이 합니다. 이 중에서 제가 자주 쓰는 regex만 알아보겠습니다. regex는 패턴에 맞지 않으면 실패하게 됩니다. 예를 들어, ResRequest schema의 x는 str이고, "^[0-9a-zA-Z]{1,5}$"만 허용한다고 해 보겠습니다. 이것은 대소문자나 숫자로만 이루어진 길이 1에서 5 사이의 문자열만 허용한다는 의미입니다.

post /res 요청이 날라왔을 때 불리는 메서드는 위와 같습니다. 이제 post /res 요청을 날려보겠습니다.

문자열 "12-45"를 보내보겠습니다.

그러면, 정규식에 맞지 않기 때문에, 422가 떨어지게 됩니다.

fastapi pydantic root validator를 알아봅시다.

코딩강아지 — Tue, 6 Jun 2023 23:46:13 +0900

fastapi의 pydantic에는 validator가 있습니다. 이 중에는 전체 schema에 대해 검증을 하는 root_validator가 있습니다. 쉽게 이야기 하면, 필드 값들의 조합이 맞는지 검증하기 위해 주로 쓰입니다. 대표적인 예로 비밀번호 재설정의 경우, 필드 2개가 있을 겁니다. 보통, newPassword, checkNewPassword로 할 텐데요. 이 두 개가 같아야 하는 검증 조건을 추가해야 할 때 쓰여요. 두 개의 필드 값을 비교하고 있잖아요? 예제를 통해 어떻게 쓰는지 간단하게 알아보겠습니다.

먼저 router입니다. ResRequest 스키마를 받아서 처리를 해 주는 post /res가 있습니다.

schema.py에 있는 ResRequest입니다. 정수를 받는 x와 y가 있습니다. check_x는 필드 x의 값을 체크한 다음에 값을 리턴해 줍니다. 여기에서는 -1을 곱해서 리턴해 주었습니다.

다음에 @root_validator입니다. cls와 values를 받습니다. 그리고 pre=True라고 되어 있습니다. 아까 validator("x")는 pre 옵션이 붙어 있지 않았는데 무엇을 의미할까요? 이는, root validator가 res_request_validator x를 validation 하는 함수보다 먼저 수행된다는 것을 의미합니다.

values.get("x"), values.get("y")로 실제 필드 이름이 x와 y에 들어있는 값을 얻어올 수 있습니다. 저는 이 두 필드값을 가지고 검증을 하였는데요. x + y가 0보다 작으면 ValueError를 떨어트렸습니다.

이제 /res에 필드 x의 값 -20, y의 값을 3으로 하고 보내봅시다.

그랬더니 422가 나오면서 x + y가 0보다 크거나 같아야 한다고 뜹니다. 왜냐하면 x와 y값을 더하면 -17 < 0이기 때문입니다. 0보다 크거나 같다는 조건을 만족하지 않습니다. 당연하게도 check_x 함수를 타지 않았습니다. 왜냐하면 먼저 root_validator가 나와버렸기 때문입니다.

이제 x에 -3, y에 3을 넘겨봅시다.

그러면 위와 같은 결과가 response로 날라오게 됩니다. 이건 왜일까요? root_validator가 통과하고, 필드 x에 대한 validator가 실행되었기 때문입니다. check_x는 x를 -x로 바꿔주는 것이기 때문에, request로 날라온 x 값에 -1을 곰한 3이 response로 나오게 됩니다.

여기까지 정리. root_validator는 schema의 여러 필드를 한꺼번에 검증하기 위해 사용한다. 예를 들자면 필드 x와 y의 값으로 검증을 해야 할 때. 혹은 조합이 맞는지 틀린지 검증할 때 많이 사용합니다.

check_x의 validator에 pre=True를 넣어주었습니다.

다음에 root_validator는 pre 옵션을 넣어주지 않았습니다. 이 경우, check_x 다음에 res_request_validator 순으로 수행됩니다.

이제 요청을 요래 다시 날려보겠습니다. 그러면, check_x에 의해 x가 20이 됩니다. 이 상태에서 root_validator가 수행됩니다. x와 y 값의 합은 20에 3을 더한 23입니다. 이는 0보다는 큰 수치입니다.

따라서 아까와는 다르게 에러 없이 수행되었음을 볼 수 있습니다.

파이썬 한 줄을 입력받을 때 쓰는 input 함수에 대해서 알아봅시다.

코딩강아지 — Mon, 5 Jun 2023 00:57:30 +0900

파이썬에는 한 줄을 입력받기 위한 함수로 sys.stdin의 readline만 있는 것이 아닙니다. 기본적으로 input()이라는 built in 함수를 제공합니다. 저 함수가 무엇인지 간단하게 알아보겠습니다.

먼저 1.txt에는 위와 같은 내용이 있습니다. 1 abcde, 그리고 2. 이렇게 2개의 줄이 있습니다.

input 함수를 읽어봅시다. standard input (stdin)으로부터 string을 읽는다고 되어 있습니다. 그리고 개행 문자는 strip 된다고 되어 있습니다.

예제를 하나 보겠습니다. for loop로 5번 루프를 돌립니다. 각 loop마다 input()을 호출하고, 받은 문자열을 출력합니다. 입력을 1.txt에서 받아보겠습니다. 윈도우 powershell에서는 아직 redirection이 지원되지는 않기 때문에, type 명령어와 |를 써야 합니다. type으로 파일의 내용을 출력하고, 파이프로 python main.py에 type의 결과값을 python ~의 입력값으로 넘기는 식입니다. 링크에 설명을 간단하게 해 놓았으니 참고해 보시면 좋겠습니다.

물론 git bash를 설치하면 그런 거 없이 그냥 redirect 문자를 쓰시면 됩니다.

결과가 어떻게 나올까요? 1번째 줄에 1 abcde, 2번째 줄에 2가 출력됩니다. 그리고, EOFError가 나옵니다.

그렇기 때문에, try except로 input() 을 호출하는 부분을 감싸주어야 합니다. 파일의 끝을 만나서 더 이상 입력을 받을 수 없는 경우 EOFError를 발생시키기 때문입니다. EOFError에 걸렸을 때, while loop를 빠져나가기 위해 break를 걸었음을 볼 수 있습니다. 이제 다시, 실행시켜 보겠습니다.

1 abcde, 2가 정확하게 출력되고 종료되었음을 알 수 있습니다. 정리하면 input 함수는 한 줄을 입력받는 함수인데, 파일의 끝을 만나면 EOFError 에러를 발생시킵니다. 고로, 파일의 끝을 판단할 때 EOFError를 catch 하면 됩니다. sys.stdin의 readline보다는 느리기 때문에 빠른 입출력이 필요한 경우, 이 함수 대신 sys.stdin의 readline을 사용하는 것을 권장합니다. ~~제가 출제한 모의 코딩테스트에 유독 그런 것이 많을 겁니다.~~

이제 예제 하나만 더 보겠습니다. 1.txt에 있는 2개의 수가 있습니다. 이 둘을 입력받아서 더한 값을 출력하려고 합니다.

이럴 때, split() 함수와 map 함수를 이용하면 됩니다. 먼저, split()로 white 문자를 기준으로 토큰을 분리합니다. 그러면, ["3", "5"]가 될 겁니다. 이제, 이 원소들에 int 함수를 apply 합니다. 이제 "3", "5"가 3, 5가 됩니다. 적용된 결과를 소모시키면 됩니다. n과 m은 각각 3과 5를 가리킵니다. map 함수에 대해 간단하게 원리를 보려면 이 링크를 참조하시면 좋겠습니다.

이제 ans에 n과 m을 더한 값을 넣고 값 ans를 출력합니다.

결과는 8이 나옵니다.

파이썬 sys.stdin에 있는 readline 함수로 여러 줄 입력을 받아봅시다.

코딩강아지 — Sat, 3 Jun 2023 23:57:23 +0900

파이썬에는 문자열을 입력받는 방법이 몇 가지 있습니다. 백준에서는 sys.stdin에 있는 readline을 많이 쓰는데요. 간단하게 알아보도록 하겠습니다.

먼저 python의 sys.stdin에 있는 readline은 한 줄씩 입력을 받는데요. 아무 것도 없는 경우에 빈 배열을 돌려줍니다. 만약에 한 줄에 아무 것도 없고 개행만 있는 경우에는, 개행이 있기 때문에 이야기가 달라집니다. 예제를 보겠습니다.

우리는 빈 배열이 리턴되면, 루프에서 빠져나가야 한다는 것을 알고 있습니다. while True: 로 계속 입력을 받습니다. 그런데 if not s: 이면 break를 겁니다. 배열의 경우 빈 배열일 때 해당 조건이 참이 되므로, 이 프로그램은 맞게 실행되는 것처럼 보입니다. 대부분의 백준 문제의 경우 요래 해도 별 상관은 없습니다.

1.txt는 위와 같습니다. 중간에 안 보이는 문자들이 들어가 있는 줄들이 있는데요. 하나는 그냥 빈 문자열이고, 다른 하나는 탭 문자만 들어갔습니다.

xxd로 보면 위와 같습니다. 0a가 개행인 부분이고요. 09는 탭 문자를 의미합니다.

결과는 a, b, c, d만 입력받았습니다. 왜냐하면, sys.stdin.readline().strip() 때문에, 양 끝의 개행, 탭 등이 제거되었기 때문입니다. 아무런 인자가 제공되지 않았으므로 화이트 문자들이 제거되었고, 개행과 탭은 화이트 문자에 속합니다. 고로, 5번째 줄을 입력받고 함수 strip으로 처리했을 때 빈 문자열이 나올 수 밖에 없을 겁니다.

어떻게 고치면 될까요? 먼저 sys.stdin.readline()을 먼저 받습니다. 이 결과를 가지고 검사를 하면 됩니다. 만약에 파일의 끝이여서 더 이상 받을 수 없는 경우, if not (s := input()): 에 의해 break가 걸립니다. :=를 왈러스 연산자라 하는데요. 해당 연산자에 대한 간단한 설명은 링크 글을 참고하시면 됩니다.

[관련글]

파이썬 왈러스 연산자에 대해 간단하게 알아봅시다.

다시 실행시켜 보니, 이번에는 의도한 대로 제대로 받았음을 알 수 있습니다. 정리하면 sys.stdin.readline()으로 입력을 계속 받습니다. 만약에 리턴 값이 빈 문자열이라면 반복문을 빠져나오게 하면 됩니다. 그런데 7번째 줄에 s = s.strip()이 들어갔습니다. 이는 왜 그럴까요?

문자열에 저장되어 있는 문자들을 수로 변환시켜서 출력해 보겠습니다.

그러면 요래 되는데요. 10은 개행을, 9는 탭을 의미합니다. 불필요한 개행이 붙었기 때문에 strip() 처리를 하지 않으면 개행이 한 번 더 출력되는 상황이 벌어지게 됩니다.

s.strip()의 경우에는 어떨까요?

이 경우 10, 9와 같은 양 끝에 붙은 white 문자들이 제거되게 됩니다. 만약에 개행 문자인 '\n'만 제거하려면 strip()에 인자를 넣어 버리면 됩니다.

s.strip('\n')은 양 끝에 붙은 '\n'을 제거해 줍니다.

다시 실행시켜 보면, 아까와는 다르게 10, 즉 양 끝에 붙은 개행문자만 제거되었음을 볼 수 있습니다.

fastapi alembic revision 명령어를 쓸 때 마이그레이션 버전을 커스텀하게 생성해 봅시다.

코딩강아지 — Wed, 31 May 2023 23:59:29 +0900

alembic으로 migration을 하다 보면 이상한 코드가 먼저 나옴을 알 수 있습니다. 마이그레이션 파일을 관리할 때 먼저 생성된 파일이 위에 오면 편할 겁니다. 어떻게 하면 좋을까요? 예를 들어, 0001_xxx, 0002_xxx 순으로 오게 하고 싶다면요? 그렇게 하면 버전 관리가 보다 편해질 겁니다.

alembic revision --autogenerate -m "init_script"를 쳐 보겠습니다.

그러면 앞에 fbe53.. 이 생성됨을 볼 수 있습니다. 랜덤하게 생성된 문자열이기 때문에 보기가 영 편하지 않습니다. 문서를 보면, context의 configure의 process_revision_directives는 "revision" --autogenerate 옵션일 때 트리거가 된다고 합니다.

그 전에 ScriptDirectory에 대한 설명을 봅시다. 이것은 current revision을 얻어오기에 매우 유용하다고 설명이 되어 있습니다. 위와 같이 얻어온다고 되어 있습니다. 이를 응용하면 아래 코드와 같이 작성하실 수 있습니다.

요러한데요. 간단하게 소개만 하겠습니다. context와 directives가 중요합니다. context는 현재 head의 버전을 가지고 오기 위함입니다. 42번째 줄에 head_revision이라고 가져옴을 볼 수 있습니다. 다음에, new_rev_id를 생성하는데요. head_revision이 없는 경우는 아직 마이그레이션 파일이 아무것도 없는 경우입니다.

고로, 이 경우에는 1번을 표기해야 합니다. 그렇지 않으면 000x_{uuid}꼴이라면 앞에 4자리만 가져오면 되겠지요. 44번째 줄에 보면, int(head_revision[:4])를 볼 수 있는데요. 이는 앞에 수 4개만 끊어오는 것입니다. 다음 45번째 줄은 migration_script의 rev_id에 무언가를 집어넣는 것입니다. 버전 번호에 uuid4를 추가함을 볼 수 있습니다. 이는, alembic에서는 앞에 revision으로 head 등을 판별하기 때문입니다.

이 rev_id는 겹치지 않게 구분짓는 게 중요합니다. 저는 뒤에 uuid가 오게 하였습니다. 이제 남은 것은 migration_script.rev_id 부분입니다. 이는 문서의 마지막 부분을 보면 대략적으로 유추할 수 있습니다. autogenerate를 할 때 이 부분의 속성들을 건드리면 새로운 버전의 파일을 생성할 때 넘겨지는 파라미터 등을 변경할 수 있다.

이로 미루어 보았을 때, 45번째 줄이 하는 것은 revision_id를 제가 원하는 이름인 000x_{uuid4}로 변경한다고 유추할 수 있습니다.

다음에 run_migrations_offline의 process_revision_directives에 gen_revision을 추가해 줍니다. 이 함수는 제가 revision을 --autogenerate 하였을 때, 호출되는 함수입니다. 이 함수를 통해, 리비전이 custom하게 생성됩니다.

run_migration_online도 수정합니다. context.configure 부분을 수정하시면 됩니다. 이제, alembic revision --autogenerate -m "message"로 마이그레이션 파일을 생성하겠습니다.

그러면 요런 파일이 하나 생성됩니다. 0001_938e.. 이 부분입니다.

이제 alembic_version 테이블을 보겠습니다.

그러면 version_num이 0001_938e379a0cb5로 생성되었음을 볼 수 있습니다. 이게 revision id인 셈입니다. 당연하게도, 해당 방법은 revision --autogenerate 명령을 쓸 때에만 적용되기 때문에, merge를 할 때에는 적용되지 않습니다.

굳이 수동으로 하려면, merge heads를 할 때 --rev-id 옵션을 주면 revision id를 커스텀하게 줄 수 있으니 이를 이용하면 되겠습니다.

파이썬 ordereddict move_to_end에 대해 알아봅시다.

코딩강아지 — Mon, 29 May 2023 23:59:42 +0900

파이썬의 orderedDict에 대해 조금 더 알아봅시다. 이전에 이 글에서 popitem에 대해 간략하게만 설명드리고 넘어갔습니다. 여기 조금 더 심화된 내용을 학습해 보겠습니다.

OrderedDict의 경우, 들어온 순서가 유지되는 딕셔너리입니다. 고로 lru와 같은 것과 잘 맞는다고 했습니다. 예제 하나를 볼 건데요. 자세히 분석해 보겠습니다.

먼저, OrderedDict 객체를 하나 선언할 거에요. 그리고 "a", "b", "c" 순서대로 넣었습니다.

다음에 lru를 출력하고, 가장 첫 번째 원소를 출력할 거에요.

그러면 출력 결과가 이렇게 나와요. 이것에 대해서 먼저 해석해 보겠습니다. 들어온 순서를 유지하는 것이 OrderedDict이라고 했어요. 고로, 이 때 그림은 아래와 같이 그려집니다.

여기까지는 대강 이해되시리라 믿습니다. next(iter(lru)) 이 부분은 무엇일까요? 일단, lru 역시 순회 가능한 무언가이기 때문에 이터레이터가 있습니다. 순방향 이터레이터는 처음부터 끝까지 탐색하는 것이고, 역방향은 역순으로 탐색하는 것입니다. next(iter)는 현재 이터레이터가 가리키는 원소를 리턴하게 되는데요.

처음 녀석인 "a"를 가리키므로 a를 돌려줍니다. 만약에 또 다시 next를 호출하면, b, c 순으로 순회가 이루어질 겁니다.

lru.move_to_end("a")가 있는데요. 오늘의 핵심입니다. 이것이 대체 무엇인가? 특정 키 값을 맨 마지막으로 보내버립니다. 즉, "a"가 제일 마지막에 추가된 것처럼 해 버린다는 의미입니다. LRU에서는 더 이상 캐시에 저장할 수 없을 때 가장 오래 전에 접근한 것을 제거해 버립니다.

키가 없으면 KeyError를 떨구기 때문에, lru를 구현한 경우, 이미 있는 키에 access 하는 용도로 쓰이게 됩니다.

move_to_end("a")를 하면 어떤 일이 일어나는가? a를 맨 뒤로 보낸다고 했지요? 그러면, a를 제거한 다음에 가장 마지막 위치에 보내버립니다.

요렇게요. 이 작업을 매우 빠르게 끝낼 수 있어요. 왜냐? 키 "a"가 있는 위치를 hash로 빠르게 찾을 수 있습니다. 그리고, 위치만 알면 List는 원소를 제거하고 추가하는 연산을 매우 빠르게 끝내버릴 수 있습니다. lru 효율적으로 구현 뚝딱 했습니다. 이 문제 풀 수 있겠습니다.

이제 next(iter(lru))와 next(reversed(lru))의 결과값은 예측할 수 있습니다. 전자는 b이고, 후자는 a입니다.

요기까지도 별로 어렵지 않습니다. 이제 popitem의 last 인자는 무엇을 의미할까요? 어느 것의 last일까요?

7번째 줄까지 수행하면, b, c, a 순으로 오래된 순입니다. 고로 b가 먼저 올 겁니다. last가 False라는 의미는 맨 처음의 원소인 'b'가 제거된다는 것입니다. 즉, 가장 오랫동안 접근하지 않은 원소가 제거되는 것과 동일합니다. 8번째 줄이 수행된 후 상태는 아래와 같이 변합니다.

이제 lru.popitem(last=True)를 호출합니다. last는 위 그림에서 "a"입니다.

따라서 "a"가 제거되게 됩니다.

리눅스 passwd 명령어를 알아봅시다.

코딩강아지 — Sat, 27 May 2023 23:56:51 +0900

안녕하세요. 이번 시간에는 리눅스 passwd 명령어를 알아보겠습니다.

먼저 cho2 유저를 추가합니다. useradd -m cho2를 입력하면 cho2의 홈 디렉토리도 같이 생성합니다.

passwd 명령어는 유저의 패스워드를 변경하는 명령어입니다. root의 비밀번호를 설정할 때에는 passwd만 입력하고 비밀번호를 재설정하면 됩니다. 생각보다 리눅스 초기 설정할 때 많이 쓰이게 되니 알아두면 좋습니다.

cho2의 암호를 설정해 보겠습니다.

다음에 su cho2를 입력합니다. 암호를 입력하면, 다른 쉘이 하나 뜨게 됩니다. whoami를 입력하면, 현재 접속하고 있는 유저를 알려주는데요. cho2라고 되어 있습니다. cho2로 로그인을 성공했습니다.

여기서 끝나면 뭔가 섭섭할 거 같으니, 다른 작업을 해 보겠습니다. 계정 비활성화, 잠금을 하는 방법도 같이 알아봅시다.

passwd의 -l은 패스워드를 lock 합니다. 패스워드 인증 방식을 쓰지 못하게 만듭니다. 이 옵션은 단순하게 패스워드를 못 쓰게 만드는 것일 뿐입니다. 인증 방법은 패스워드 말고도 많습니다. ssh 키와 같은 것으로도 인증할 수 있어요. 이런 것까지 막지는 못해요. note는 이를 의미합니다.

한 번 실습해 봅시다.

passwd -l cho2를 입력해 보겠습니다. 그러면, password changed.가 뜨는데요.

패스워드의 맨 앞에 !가 붙어있음을 볼 수 있습니다. 이는 패스워드를 쓰지 못한다는 것을 의미합니다. 다시 su cho2를 입력해서 인증을 시도해 보겠습니다.

암호를 올바르게 입력해도 되지 않습니다.

그런데 암호 말고도 인증할 방법은 많다고 했습니다. 대표적으로 ssh에 이용하는 private key입니다.

이것을 이용해서 cho2 계정에 ssh로 접속해 보겠습니다.

접속이 됩니다. 이는 password로 인증을 하지 않았기 때문입니다.

진짜로 유저를 deactivate를 시키려면 usermod를 이용해야 합니다. usermod cho2 --expiredate 1을 입력해 보겠습니다. 이는 만료일이 1970년 x월 x일이라는 의미입니다.

이 명령을 적용한 후에 다시 su cho2로 로그인을 시도해 보겠습니다. 그러면, cho2의 계정이 만료되었다고 뜨면서 관리자에게 문의하라는 에러가 뜨게 됩니다.

shadow 파일을 보면, 마지막 필드에 1이라고 쓰여져 있음을 볼 수 있습니다. 이는, 계정이 만료된 date를 의미합니다. 1970년 1월 1일부터의 날을 의미하니 --expiredate 1의 의미는 1970년 어느 날에 만료가 되었다는 의미입니다. 계정을 expire, 즉 비활성화 시키는 것만으로도 못 쓰게 만들 수 있다. 정도만 알아두셔도 되겠습니다.

java arrays fill 메소드와 setAll 메소드의 차이점을 알아봅시다.

코딩강아지 — Fri, 26 May 2023 21:25:04 +0900

java의 Array에는 배열의 모든 원소를 특정한 값으로 초기화 하기 위한 메서드가 있습니다. fill과 setAll이라는 메소드입니다. 간단하게 차이점을 알아보겠습니다.

먼저 fill입니다. specified int value. specified value. 특정한 값으로 모든 원소를 초기화 합니다. 예를 들어 배열 내의 원소를 모두 5로 초기화 시키거나 할 때 쓸 법 합니다. 이 메서드는 int형 배열 뿐만이 아니라, long, char, ... 등의 배열을 받기도 합니다. 오버로딩 되어있다고 보면 됩니다. 이 블로그에서는 int형 배열만 다룹니다.

예제를 보겠습니다.

단순하게 Arrays.fill(a, 5);를 호출합니다. 그러면 10개의 원소를 저장하는 배열의 원소들이 모두 5로 초기화 됨을 볼 수 있습니다.

실행 결과는 위와 같습니다.

setAll은 array와 generator를 받습니다. generator는 하나의 함수입니다. 인덱스에 대해 받아들일. 그리고, 해당 위치에 대해서 바라는 값을 생산합니다. 이게 무슨 이야기인가? 배열은 위치가 있습니다. 인풋은 위치, 아웃풋은 위치가 들어오면 뽑아내는 값을 의미합니다. 적용되는 함수에 의해서. 다시 정리해 보겠습니다.

function(위치)를 정의하는 generator이다. function(x)는 x번째 위치에 대해 적용될 값이다. 고로, f(x) = 5이면 배열 내의 모든 값을 5로 초기화 하는 것과 동치일 겁니다. 예제를 보겠습니다.

Arrays.setAll(a, x -> 5); 랍니다. x는 위치를 의미합니다. 모든 위치에 대해서 output이 5입니다. 그러면 값이 어떻게 나올까요? 0번째 위치도 5로, 1번째 위치도 5로, ... , 마지막 위치도 5로 초기화 합니다. 즉, 모든 원소를 5로 초기화 합니다.

실행 결과는 위와 같습니다. 이러면 Arrays.fill과 별 차이가 없어 보입니다? 그런데 하나 다른점은 x번째 위치에 적용될 값을 function으로 적용할 수 있다는 점입니다. 예를 들어, i번째 위치의 값은 2*i로 적용한다고 해 보겠습니다.

그러면, 위와 같이 적용할 수 있습니다. setAll의 2번째 인자에 index -> 2 * index를 넣었음을 알 수 있습니다. 이는 index번째 위치에 있는 값은 2 * index를 적용하라는 의미입니다.

실행 결과는 위와 같습니다.

또 다른 차이점은 없을까요? Object 배열을 생각해 봅시다.

x -> new Obj(3)을 generator로 넘겨주었습니다. 이 Obj는 x라는 필드만 가집니다. 그리고 0번째 원소의 필드 x를 10으로 바꾸었습니다. 결과는 어떻게 나올까요?

Obj의 toString은 필드 x값만을 뽑는 것입니다. 결과를 보니까, 0번째 원소만 10으로 바뀌었음을 볼 수 있습니다. 이로 미루어 보았을 때, setAll은 루프를 돌면서 generator의 평가식을 수행함을 볼 수 있습니다. 그렇기 때문에, new Obj(3);을 10번 호출하게 됩니다. 고로 필드 x의 값이 3인 오브젝트가 10개가 생성되게 됩니다. 별개의 object이므로, 한 개의 필드만 10으로 바꾸어도, 나머지는 영향을 미치지 않습니다.

반면, fill은 이야기가 다릅니다. 결과가 어떻게 나올까요?

모두 10이 나왔습니다. 객체의 참조값이 인자로 들어갑니다. 고로, 0번째 원소부터 9번째 원소까지 같은 객체의 참조값이 들어갑니다. 얕은 복사가 되어버리는 셈입니다. 이 차이점도 염두에 두면 좋겠습니다.

postgresql 어제 날짜 내일 날짜 구하는 방법을 알아봅시다.

코딩강아지 — Wed, 24 May 2023 23:21:57 +0900

postgresql에서 어제 날짜와 내일 날짜를 구하는 방법을 알아보겠습니다.

현재 시간을 구하는 함수는 now()입니다. 여기서 '1 days'::interval을 뺀 값을 yesterday로 명명하였습니다.

결과를 볼까요? 그랬더니, 2023년 5월 23일 22시 24분 16.752초 +0900이 나옵니다.

now() 리턴값의 type을 pg_typeof라는 함수로 할 수 있습니다.

timestamp with time zone이라고 되어 있습니다. 즉 timezone입니다. 이 문서에서 table 9.32는 Date와 Time을 연산할 때 어떤 결과가 나오지에 대해서 설명합니다. timestamp와 interval을 더하면 timestamp가 나오게 됩니다. now()에 '1 days'::interval을 빼 버렸는데요. 이 경우, 1일 이전의 timestamp가 나오게 됩니다.

여기까지 별로 어렵지 않지요? 다음으로 넘어갑시다.

남은 과제는 어떻게 timestamp를 YYYY-MM-DD 꼴로 바꾸냐는 것입니다. 이것 역시 문서를 보면 쉽게 파악할 수 있습니다. to_char라는 함수로 timestamp와 string format을 주면 형식에 맞게 문자열로 변환해 버리게 됩니다.

현재 시각에서 1 days를 빼 버렸기 때문에 어제 날짜인 2023년 5월 23일이 나옵니다. 이를 YYYY-MM-DD 형식으로 바꾸려고 합니다. 4자리 년도, 2자리 월, 2자리 일 형식입니다. 고로 위와 같이 작성하시면 됩니다.

2023-05-23. 의도하던 결과가 나왔습니다. 고로 하루 전 날짜를 구한다면 to_char(now() - '1 days'::interval, 'YYYY-MM-DD') 로 해 주면 되겠군요. 내일 날짜는 어떻게 구할까요?

그냥 now()에 '1 days'::interval만 더하면 됩니다. 그러면 하루 지난 시각을 표시하게 됩니다.

2023년 5월 25일이 나오네요. 요약하면 현재 timestamp에 '1 days'::interval을 더하면 내일, 빼면 어제를 구할 수 있습니다.

1주일 후의 날짜를 구할 수도 있을까요? 당연합니다. interval은 week 또한 표현할 수 있습니다. 뒤에 W, 혹은 Weeks를 붙이면 됩니다. 예를 들어 '2W'는 2주를 의미합니다. 이것 말고도, interval에는 몇 년을 뜻하는 'Y', 몇 달을 뜻하는 'M', 몇 시간을 뜻하는 'H', 몇 분을 뜻하는 'M', 몇 초를 뜻하는 'S'가 있어요. 해당 쿼리는 현재 시각으로부터 1주 뒤 시각을 구하는 것입니다.

고로, w_after에는 7일이 지난 시각이 표시되게 됩니다.

파이썬 enum의 원소를 random하게 가져오는 방법을 알아봅시다.

코딩강아지 — Mon, 22 May 2023 23:58:30 +0900

파이썬에서 enum의 원소를 random하게 가져오는 방법을 알아보겠습니다.

먼저, Enum을 상속받은 A 클래스를 보겠습니다. 이름이 A이고 값이 1인 것, 이름이 B이고 값이 3인 것, 이름이 C이고 값이 5인 것, 이름이 D이고 값이 7인 것이 있습니다.

랜덤하게 뽑을 것이므로, choice와 같은 것이 필요한 것은 자명해 보입니다. 그런데 이것은 sequence가 필요하다고 뜹니다. 시퀀스의 대표적인 것은 list이니, enum의 데이터를 list로 변환해야겠네요.

rd.choice(list(A))를 해 주면, A에 있는 item 중에 랜덤하게 하나를 뽑습니다. 이게 다입니다.

실행 결과는 A.a, A.b, A.c, A.d 중에 하나가 나옵니다. 즉, list(enum_class_name)은, enum class인 enum_class_name에 있는 원소들을 리스트로 변환해 줍니다.

코드가 어떻게 실행되나 보겠습니다. Enum에서 metaclass는 EnumType임을 알 수 있습니다. 이 클래스 안에 무엇이 있을까요?

놀랍게도 __iter__ 이라는 함수에서 멈추게 됩니다. __iter__는 이터레이터를 반환해 주는 함수인데요. member_names_를 돌면서, _member_map_에 있는 것들을 꺼내옴을 알 수 있습니다. 소괄호로 묶여져 있는 것은 generator를 리턴함을 의미합니다. 결국, enum에 선언된 아이템들을 모두 가져오는 무언가를 generator로 감싼 형태가 됩니다.

이제 이 generator를 list의 생성자의 인자로 넘기면, 멤버들을 모두 가지고 있는 list를 리턴하게 됩니다.

정리하면, list(A)에서 넘겨지는 타입은 generator입니다. 한 번 next가 불릴 때 마다, A, B, C, D를 가리키는 generator가 나오게 됩니다. 중간에 metaclass의 __iter__가 호출되는 것을 보면 알 수 있습니다. generator를 list의 생성자로 넘기게 되면, 리스트가 초기화 되는 과정에서 내부에서 리턴된 generator의 원소들이 소모되게 됩니다.

고로, list(A)를 했다면 아래와 같이 나옵니다.

이제, 구축된 리스트를 바탕으로 choice를 돌리면, 4개의 enum 원소 중에 하나가 뽑히게 됩니다.

여담으로 reversed(A)도 있습니다. 이 경우, 거꾸로 나오게 됩니다. enum의 원소 중에 랜덤하게 뽑는다는 문제와는 상관은 없습니다만, 알아두면 좋을 듯 싶습니다. 정리하면 Enum을 상속받은 A가 있을 때, list(A)는 A의 원소들을 모두 가져오는 generator를 넘깁니다.

결국 list(A)는 A의 원소들을 모두 가지고 있을 겁니다. 이제 우리는 이 리스트에서 random하게 하나 뽑기만 하면 됩니다. 제너레이터에 대한 조금 더 자세한 설명은 여기를 보셔도 되겠습니다.

파이썬 pillow crop 함수를 알아봅시다.

코딩강아지 — Sat, 20 May 2023 23:39:17 +0900

pillow의 crop 함수를 알아보겠습니다.

crop 함수는 4개의 정수로 이루어진 box 정보를 넘깁니다. 각각 제일 왼쪽, 제일 위, 제일 오른쪽, 제일 아래의 좌표를 넘깁니다. 이렇게 이루어진 직사각형으로 이미지를 잘라버립니다. 알기 쉽게 그림을 하나 그려보도록 하겠습니다.

사진에서 (0, 0)은 맨 왼쪽 위 좌표를 가리킵니다. 오른쪽으로 갈수록 x 좌표가 증가하고요. 아래쪽으로 내려갈수록 y 좌표값이 증가한다고 생각하는 것이 편합니다. 이를 그림으로 나타내면 위와 같습니다. 따라서, (2, 1)은 위 그림과 같습니다. box에 (2, 1, 3, 3)을 넘기면, 아래와 같은 일이 일어납니다.

왼쪽 좌표가 2, 맨 위의 좌표가 1, 오른쪽 좌표가 3, 맨 아래의 좌표가 3입니다. 이를 그림으로 나타내면 노란색 영역이 됩니다. 이 영역으로 잘라지게 됩니다. 하늘색으로 칠해지는 부분은 버려지는 셈입니다. 즉, 리턴이 될 때는 노란색 영역만 나오게 되는 것입니다. 이제 실습을 하나 해 보겠습니다.

먼저 gif_ex.gif입니다.

img.crop으로 이미지를 자르는데요. box의 정보로 (300, 300, 900, 900)을 넘겨주었습니다. 좌상단 좌표가 (300, 300)이고 우하단 좌표가 (900, 900)인 직사각형으로 잘라진 이미지를 돌려주라는 것입니다.

결과를 보니 요래 나오네요. 윈도우 그림판 프로그램으로 정말 이 결과가 맞는지 검증해 보겠습니다. 보기에서 격자와 눈금자를 모두 보게 설정합니다.

그리고 (300, 300)을 왼쪽 위 좌표로 (900, 900)을 오른쪽 아래 좌표하는 직사각형을 그려보았습니다. 동일한 영역을 그렸음을 알 수 있습니다.

이제, (1500, 2000, 3500, 2500)을 box 정보로 넘기면 어떻게 될까요? 왼쪽 위 좌표가 (1500, 2000)이고 오른쪽 아래 좌표가 (3500, 2500)인 직사각형으로 잘린 이미지가 나타납니다. 결과부터 보겠습니다.

노트북 키보드 부분이 일부 나와 있음을 볼 수 있습니다. 가로 2000픽셀, 세로 500 픽셀이 나왔습니다. 맞게 나온 것 같습니다만, 그림판으로 검증해 보겠습니다.

제가 표시한 직사각형 영역은 위 상단이 (1500, 2000)이고 오른쪽 하단이 (3500, 2500)입니다. 정확하게 키보드의 일부분만 나오므로, 맞게 나옴을 볼 수 있습니다.

pillow resize 함수를 알아봅시다.

코딩강아지 — Thu, 18 May 2023 07:15:15 +0900

pillow에서 thumbnail 함수를 열어보면, 안에서 resize 함수를 호출함을 볼 수 있습니다. 이 글에서는 대략적으로 언급만 하고 넘어갔습니다. 오늘은 resize를 알아보겠습니다.

[관련글]

python pillow resize 함수를 알아봅시다.

이미지 하나를 열어보겠습니다.

288 x 288px인 이미지입니다. 저는 윈도우 11의 그림판을 실행하였습니다. 크기 조정 및 기울이기가 있습니다.

가로와 세로 사이에 있는 링크 버튼을 활성화 시켜 보겠습니다. 그러면 가로 크기와 세로 크기의 비율이 일정하게 유지됩니다. 가로를 144 픽셀로 바꾸면, 세로도 자연스레 144로 바뀝니다.

일정한 비율로 줄어들었습니다. thumbnail과 동일하다고 할 수 있어요. 다른 점은 thumbnail은 사진의 원본 크기보다 크게 조정되지 않는다는 것입니다.

링크 버튼을 비활성화 시킨 상태로 조정해 보겠습니다. 원래 288 x 288 px이였습니다만, 288 x 144px로 조정해 보겠습니다.

그러면 가로만 2배로 늘려진 사진으로 되었음을 알 수 있습니다.

가로 288, 세로 440으로 조정해 보겠습니다. 그러면 세로만 약 1.5배 늘려진 사진이 됨을 알 수 있습니다.

pillow의 resize는 요청한 size로 사진을 늘리거나 줄입니다. 원본 사진은 7724x5148의 jpeg 파일입니다.

9000 by 3000으로 resize를 시켜보겠습니다.

그랬더니, 가로로 길쭉한 사진으로 변환되었음을 볼 수 있습니다.

600 by 3000으로 변환시킨 경우에는 위와 같은 사진이 나왔음을 알 수 있습니다. 즉, 원래 사진에서 가로 크기를 a배율로, 세로 크기를 b배율로 조정하였습니다. 그럴 때, 원래 사진에서 (x, y)에 있었던 점은 새롭게 resize된 사진에서는 (ax, by)의 위치에 있다고 생각하시면 됩니다. 예를 들어, 900 by 900 사진을 900 by 300으로 resize를 했다고 가정해 보겠습니다.

그러면 가로 배율은 1비율, 세로 배율은 1/3이 되었습니다. 따라서 원래 (300, 600)에 있었던 점은 새롭게 resize된 사진에서 (300, 600/3)의 위치에 있습니다. pillow의 thumbnail의 내부에서도 resize를 호출합니다. 다른 점은 resize를 호출하기 전에 비율을 맞추는 전처리를 합니다.

python 날짜를 주차로 바꾸는 방법을 알아봅시다.

코딩강아지 — Wed, 17 May 2023 01:02:33 +0900

datetime의 날짜가 몇 번째 주에 속하는지 출력하려고 합니다. 이 때 잘못 적용하면 의도치 않는 결과가 나타날 수 있습니다. 특히, 1월 새해 근처에 있는 코너 케이스로 테스트를 해 보셔야 어떤 주에 속하는지 정확하게 알 수 있습니다.

먼저 2020년 12월 25일부터 14일 동안 년도와 몇 번째 주차인지 뽑는 프로그램을 만들어 보겠습니다. strftime으로 datetime을 문자열로 변환하는데요. 변환 문자열이 '%Y-%W'임을 알 수 있습니다. 년도와 주차가 뽑히게 되는데요. iso 8601 형식이 아닙니다. 어떻게 뽑히는지 보겠습니다.

2020년 12월 28일이 2020년 52번째 주차로 뽑힙니다. 그리고 2021년 1월 1일이 2021년 0번째 주차, 1월 4일이 1번째 주차로 뽑히게 되는데요. 2020년 12월 근처의 달력을 보겠습니다.

2020년 12월 28일은 월요일입니다. 그래서 주차가 바뀝니다. 다음에 2021년 1월 1일에 주차가 또 바뀌었음을 알 수 있는데요. 이는 2020년에서 2021년으로 바뀌었기 때문입니다. 다음에 2021년 1월 4일은 월요일입니다. 따라서, 2021년 1월 4일은 주차가 또 바뀝니다.

즉, strftime에서 %Y-%W를 입력하면, 연도가 바뀔 때와 월요일이 되었을 때 주차가 바뀌게 됩니다. 그렇기 때문에 1월 1일이 월요일이 아닌 경우 의도치 않은 결과가 나올 수 있습니다.

이를 해결하기 위해서는 Week와 Year를 ISO year, week로 바꾸어야 합니다. ISO year는 %G, ISO week는 %V입니다. 이는 문서를 보면 알 수 있습니다.

다시 2020년 12월 25일부터 14일동안 iso 형식의 year와 week를 뽑아보겠습니다.

그러면 아까와는 다르게, 2021년 1월 4일, 2020년 12월 28일에 주차가 바뀜을 알 수 있습니다. week가 시작하는 월요일을 기준으로 주의 번호가 변하게 됩니다. 2020-53이 1월 1일이 되었다고 바뀌지 않는 것을 보면 알 수 있습니다.

2022년에서 2023년으로 변하는 데이터의 경우에도 제대로 작동할까요?

2022년 12월 26일에 월요일이 되었습니다. 그리고, 2023년 1월 2일에 월요일이 됩니다. 따라서, 주차를 정확하게 구했다면, 2022년 12월 26일의 week와 2023년 1월 1일의 week가 같아야 합니다. 정말 그런지 보겠습니다.

2022-52로 같음을 알 수 있습니다.

isocalendar를 써도 동일한 결과를 얻을 수 있습니다. 이것은 iso year, week, day를 튜플 형태로 리턴하게 되는데요. 맨 먼저 나오는 것이 year, 두 번째로 나오는 것이 week, 마지막으로 나오는 것이 day입니다.

사용법은 어렵지 않습니다. datetime의 datetime 객체 dt가 있다면, dt.isocalendar()를 호출해 주면 iso year, week, day가 있는 튜플이 나오게 됩니다. 이 정보를 그대로 쓰면 됩니다. 프로그램의 실행 결과는 아래와 같습니다.

2022년 12월 31일과 2023년 1월 1일이 같은 주차로 묶였음을 알 수 있습니다.

pillow thumbnail 함수에 대해 알아봅시다.

코딩강아지 — Tue, 16 May 2023 00:14:17 +0900

안녕하세요. 이번 시간에는 Pillow의 thumbnail 함수에 대해서 알아보겠습니다. 말 그대로 큰 이미지의 썸네일을 보여주는 것이므로, 같은 비율로 축소한 그림을 보여줄 거라는 것을 알 수 있습니다. 보통 size 인자를 많이 쓸 것이니, 이 부분만 간단하게 보도록 하겠습니다.

먼저, thumbnail은 이미지를 썸네일로 만듭니다. 해당 메소드는 주어진 크기보다 더 크게 사진을 만들지 않습니다. 예제 이미지 몇 개로 실험해 보겠습니다.

먼저 test.jpeg입니다. 이 파일은 7724 x 5148 jpeg 형식의 10.5메가짜리 파일입니다.

먼저, test.jpg입니다. 이미지를 연 다음에, thumbnail의 size 인자에 (256, 256)으로 넘겼습니다. 썸네일화 시킨 결과를 test_0.jpeg로 저장하였습니다.

그랬더니, 256x171 jpeg 파일로 변환되었습니다. 원본 대비 가로와 세로 픽셀이 1/30으로 줄어들었습니다. 어떻게 된 것인가? 5148을 256으로 줄이면, 같은 비율로 줄였을 때, 가로가 256보다는 큽니다. 따라서, 가로를 256으로 줄이게 됩니다. 7724를 256으로 나누면 30.1이 나옵니다. 비슷한 비율로 5148을 줄이면 171이 나오게 됩니다.

이 경우에는 어떨까요? size를 가로는 256을 안 넘어가게, 세로는 128을 안 넘어가게 조정을 합니다. 가로 7724를 256으로 줄였습니다. 같은 비율로 세로를 줄이면 171이 나옵니다. 이는 128보다 큽니다. 따라서, 5148을 128로 줄입니다. 같은 비율로 가로를 줄이면 192가 나오게 됩니다.

따라서 가로는 192, 세로는 128인 jpeg 파일이 나오게 됩니다.

5760x3840 gif 파일을 (256,128)로 썸네일화 시켜 보겠습니다.

그러면 192x128로 썸네일화가 되는 것을 볼 수 있습니다. 거의 같은 비율로 줄이고, 주어진 가로, 세로 size가 안 넘어가게끔 조정하고 있음을 알 수 있습니다.

어떻게 동작하는지 간단하게 보도록 합시다. aspect는 x/y를 의미합니다. 저는 가로가 5760, 세로가 3840인 사진을 넘겼으므로, 이 값은 5760 / 3840인 1.5가 됩니다. 그런데 제가 요구한 값인 (256, 128)은 2이므로, 1.5보다는 크거나 같습니다. 따라서, 5760에 3840/128 = 30을 나눠야 합니다. 5760에서 30을 나누면 192가 됩니다.

새로운 x와 y의 값은 192, 128임을 알 수 있어요.

내부에서 resize를 호출합니다. 이 때 resize는 가로와 세로의 비율이 유지된 size를 넘겨받게 됩니다. 정리하면, pillow의 thumbnail은 2가지 일을 수행합니다. 같은 비율로 축소하는데, 주어진 가로와 세로 size보다 크지 않게 축소합니다. 예를 들어, 1000 by 1000짜리 이미지가 주어졌고, thumbnail의 size가 (10, 20)으로 주어진다면, 20 by 20으로 축소하는 게 아니라 10 by 10으로 축소합니다.

postgresql materialized view와 view의 차이가 무엇인지 알아봅시다.

코딩강아지 — Sat, 13 May 2023 23:59:34 +0900

postgresql에는 materialized view가 있습니다. 간단하게 실습하면서 알아보겠습니다.

먼저, materialized view는 아래와 같이 생성합니다. create materialized view ~ as ~. 위 문장은, m_a라는 이름의 view를 생성하는데요. select * from a가 들어왔습니다. 테이블 a의 내용을 모두 출력하는 쿼리에 대한 뷰를 만듭니다. 그러면 view와 같은 것이 아니냐? 라는 질문을 하실 수 있는데요. 쿼리의 결과가 사용된다는 점은 같습니다.

그런데, 차이가 있습니다.

먼저, 테이블 a에 들어있는 내용입니다.

이 테이블에 위 2개의 레코드를 추가해 보겠습니다.

그리고, view 하나를 생성해 보겠습니다. 이 view는 a의 전체 내용을 출력하는 쿼리를 참조합니다. 무슨 이야기냐면, 이 상태에서, 우리가 select * from v_a; 라는 쿼리를 수행하면, v_a라는 view가 a 테이블에 있는 전체 내용을 출력하는 쿼리를 참조하니까, 해당 쿼리를 수행합니다.

그러면 요래 됩니다. 이 view는 민감한 정보를 다른 유저가 못 보게 할 때에도 쓰인다고 관련 글에서 언급한 적이 있었습니다. 예를 들어, 책의 이름과 저자와 이메일이 있는 테이블이 있다고 해 봅시다. 이 중에서 이메일은 민감 정보이니, reader 권한만 가지는 유저는 못 읽게 할 수 있을 겁니다.

이럴 때, select name, author from book; 이라는 쿼리를 참조하는 view를 하나 만들어서, 해당 view에 읽기 권한을 주면 됩니다.

[관련글]

view를 생성해서 column 권한을 주는 방법을 알아봅시다.

select * from m_a;를 해 봅시다. 아무 것도 나오지 않음을 볼 수 있어요. 제가 m_a라는 실체화된 뷰를 하나 생성했습니다. 그리고 나서, 테이블 a에 레코드 2개를 추가했습니다. 그럼에도 반영이 안 된 것은 어딘가에 materialized view의 결과를 저장하고 있었는데, 새로운 결과가 어딘가에 반영이 되지 않았기 때문입니다.

그러면 어떻게 해야 할까요? refresh 명령을 이용하면 됩니다.

refresh materialized view m_a;를 입력해 봅시다.

다음에, select * from m_a; 를 입력해 보겠습니다.

그러면 데이터 2개가 새로 생성되었음을 볼 수 있습니다. 정리하면, view와는 다른 점은 결과 데이터를 저장하고 있는 무언가가 있다는 것입니다. refresh를 해야, 새로운 결과가 업데이트 된다는 것입니다. 쉽게 말하면 create materialzed view v_a as select * from a; 라는 것으로 뷰를 생성했다 해 보겠습니다.

그러면 이 시점에서, 테이블 a를 조회했을 때의 결과를 v_a가 가지고 있습니다.

별개의 공간에 가지고 있습니다.

따라서 a라는 테이블에 c라는 레코드가 추가되어도, m_a에는 아무런 영향이 없습니다.

하나 놓치면 안 되는 것이 있습니다. matrialized view는 인덱스를 선언할 수 있습니다. 인덱스를 걸 수 있기 때문에, 효율적인 = 연산이나 < 연산이 필요할 때 보다 효율적인 결과를 낼 수 있을 겁니다.

java equals vs compareto의 차이점을 알아봅시다.

코딩강아지 — Fri, 12 May 2023 23:56:18 +0900

java에는 equals랑 compareTo가 있습니다. 이 둘을 언제 쓰는지, 차이점을 간단하게 알아보겠습니다.

먼저 compareTo는 비교를 하기 위해 쓰입니다. 순서를 정하기 위해서. 뒤에 for order가 붙은 것을 보면 알 수 있습니다. 당연하게도, comparator의 compare도 같은 용도로 쓰입니다. Compares object for order. 위에서 말한 순서는 무엇일까요? 랭킹을 정한다고 생각해 봅시다.

이름과 점수로 이루어진 object가 있습니다. 우리는 점수별로 순서를 정하려고 합니다.

Obj 클래스는 이 상황에서 학생에 대한 데이터를 저장할 거에요. score와 name이 있는데요. 각각 받은 점수와 이름을 저장하고 있습니다. compareTo는 아래와 같이 오버라이딩을 하면 될 거에요.

해당 학생의 score와 다른 학생의 score를 비교했을 때, 해당 학생이 더 점수가 크다면 음수 값을 리턴해서 앞의 순서에 오게 한다.

이제 TreeMap에 점수가 5이고 이름이 A인 사람, 점수가 3이고 이름이 B인 사람, 점수가 2이고 이름이 C인 사람을 넣어 보겠습니다.

그러면, 점수가 5인 학생이 가장 앞에 왔음을 볼 수 있어요.

즉, score가 5인 사람과 3인 사람을 비교했을 때, 순서를 정하는 기준을 compareTo로 하는 것입니다. 노란색 객체가 파란색 객체보다 order가 앞에 와야 한다면 음수 값을, 뒤에 와야 한다면 0보다 큰 값을 돌려주면 됩니다. 만약에 같으면? 0을 리턴하면 됩니다.

이름이 A인 학생과 B인 학생, 그리고 C인 학생이 있어요. 점수가 모두 같으므로, 이들 각각은 compareTo의 리턴 값이 0입니다.

굳이 그림으로 그리자면 이런 상황입니다. 고로 stable sort가 아니라면, 이 셋은 어떤 순서로 와도 상관이 없게 되어 버립니다만, 오브젝트의 list는 tim sort를 씁니다.

순서는 유지됩니다. 어찌 되었던 순서를 정하는 기준을 compareTo를 오버라이딩 할 수 있어요. compareTo가 0이라는 의미는, 앞에 오나 뒤에 오나 별 상관이 없다. 정도로 해석해도 됩니다. 정렬하는 경우, stable sort인 경우 들어온 순서대로, unstable인 경우 rank가 같으면 아무렇게나 정렬될 겁니다.

여기서 질문. a.compareTo(b), 혹은 comparator.compare(a, b)의 리턴값이 0이기 때문에 두 객체는 논리적으로 동등할까요? 물론 완전히 같은 객체를 비교한다면 0이 나올 순 있습니다. 그런데 위에서도 보았다 시피 동점자가 여러 명 있는 경우, 각각의 학생들은 동등하다고 볼 수 없습니다.

단지, 5점을 맞은 학생들과 4점을 맞은 학생들의 순서를 정하기 위해 compareTo와 같은 것을 쓴 것 뿐이였습니다. 다시 말하지만 순서를 정하는 기준이 점수라고 합시다. 두 객체를 compare로 비교했을 때 0이 나왔다는 의미는, 동점자였다는 의미입니다. 비교한 결과가 0이라고 해도, 같은 학생이 아닐 수도 있습니다.

만약에 학교에 같은 이름을 가진 둘 이상의 학생이 없다고 해 보겠습니다. 그러면, 이름이 같으면 같은 학생이고, 그렇지 않으면 다른 학생이라고 할 수 있겠습니다.

그렇다면, equals를 위와 같이 override 할 수 있습니다. 단순히 name만 같으면 같은 학생이다. 라고 판별해 버리면 됩니다.

학생 s1에 대한 데이터가 있습니다. 점수가 5이고, 이름이 "A"라는군요. 학생 s2는 점수가 5이고, 이름이 "B"입니다. 이 둘을 비교했을 때에는 0이 나옵니다. 그런데, 같은 학생은 아닙니다. 왜? 이름이 다르기 때문입니다. 단지, 동점자여서 비교 함수의 리턴 결과가 0이 나왔을 뿐입니다.

s1과 s3은 어떤가요? 이름까지 같습니다. equals에서 이름이 같으면 동일한 학생으로 본다고 했습니다. 고로 3번째는 true가 나옵니다.

쉽게 정리하면, 순위를 정하기 위해 기준을 정하는 함수가 compareTo와 compare 같은 비교 함수입니다. 두 객체를 이 메서드들로 비교했을 때 0이 나왔다고 논리적으로 동일한 객체가 아닙니다. 왜? 동점자 (동순위 사람)이 있을 수 있기 때문입니다. 논리적으로 같은지를 판정하는 함수가 equals라고 할 수 있겠습니다.

java treemap compareto나 compare만 구현했을 때 제대로 동작할까요?

코딩강아지 — Thu, 11 May 2023 00:14:45 +0900

자바에는 TreeMap이 있습니다. 키 오브젝트가 Obj의 인스턴스라고 해 봅시다. Obj 클래스에서 equals를 override 하지 않고 compareTo를 비교하거나, Obj를 비교하는 방법인 comparator만 생성자로 넘기면 어떻게 될까요? 그래도 잘 동작할까요?

우리가 걱정하는 부분은 equals입니다. equals는 두 객체의 동등성을 비교합니다. 이 메서드가 어디에서 쓰이는지 TreeMap 내부에서 한 번 찾아보도록 합시다.

putAll에 등장합니다. Objects.equals이네요. comparator를 넘기는 것으로 보아서는, 비교하는 객체를 넘기는 것으로 보입니다. 따라서, 키 값과는 아무런 연관이 없습니다.

다음 replace 입니다. 이 부분도 잘 보면, value에 대해서만 equals를 보고 있음을 알 수 있어요.

valEquals 함수 안에서도 equals가 쓰이는데요. 이 메서드는 Entry 내에서 쓰입니다. 키 값에 대해서는 equals가 있으나 없으나 별 문제 없이 동작할 거 같은데요. put과 getEntry를 보겠습니다.

먼저 put입니다. 원소를 추가할 때 이 메서드가 호출되게 됩니다. 해당 부분은 comparator가 있는지 없는지를 검사합니다.

만약에 compareTo를 오버라이딩 했고, comparator를 넘기지 않았다면 812번째 줄이 수행되게 됩니다. k.compareTo의 결과값을 가지고 무언가를 수행함을 볼 수 있습니다. 여기서, cmp가 0일 때 oldValue를 바로 리턴해 버리는 것을 볼 수 있습니다.

만약에 현재 보고 있는 루트보다 넣을 키가 더 작다면 왼쪽 자식으로, 그렇지 않다면 오른쪽 자식으로 이동합니다. rb tree도 기본적으로는 key 값의 대소를 기반으로 왼쪽으로 갈지, 오른쪽으로 갈지, 탐색을 끝낼 지를 판정합니다. 고로 해당 로직이 그대로 쓰이게 됩니다. 단지 rotate 연산이 추가로 있을 뿐입니다. 고로 순서가 같은 키가 중복해서 들어오는 걱정은 compareTo로 해결이 가능합니다.

다음에 getEntry입니다. remove라던지 contains와 같이 TreeMap을 쓸 때 사용하는 주요 메서드의 경우, getEntry를 먼저 호출하게끔 되어 있습니다.

여기서도 cmp의 값을 기준으로 왼쪽으로 가고, 오른쪽으로 가는 것을 반복함을 볼 수 있습니다. 당연하게도 cmp가 0인 경우, 그냥 해당 위치를 리턴해 버립니다. 즉, key 값은 compare 기반으로 동작합니다. 따라서, 키로 이용될 것은 compareTo를 overriding 하거나, 키를 compare하는 비교 클래스를 생성자의 인자로 넣어버리면 됩니다.

두 키의 순서가 같다는 것은 어떻게 알 수 나요? compare을 한 결과가 0인 것으로 알 수 있습니다. 굳이 왜 equals를 안 쓸까요? tree는 루트에 있는 값과 키 값을 비교 (ordering)을 해서 키 값이 작으면 왼쪽, 크면 오른쪽으로 가는 식으로 동작합니다. 비교가 필요한데, 동일한지에 대해서만 판정하면 될까요? 아닙니다. 고로 비교 연산이 적합합니다. hash 계열은 equals랑 hashCode 둘 다 필요한데요. 이는 키 값을 탐색하는 방식이 다르기 때문입니다. hash 계열은 아래와 같이 동작합니다.

hashCode로 버킷값을 찾습니다.

버킷에 물려 있는 키들을 보면서 정말 같은지 동등성을 확인합니다. 물론 compareTo로 비교해서 0이면 같다고 판정하는 방법이 있을 겁니다. 그렇게 쓸 수는 있는데 어색한 용법입니다.

그런데, value의 경우 이야기가 달라집니다. 몇 가지 기능이 의도하지 않는 방향으로 동작해 버릴 수 있습니다. 대표적으로 replace 입니다.

Obj는 compareTo만 오버라이딩 되어 있습니다. replace(key, v1, v2)는 key에 대응되는 값이 v1이면 v2로 교체합니다. 이 메서드는 제대로 수행될까요?

아닙니다. 이 메서드는 내부적으로 value 값을 비교할 때 equals를 사용하기 때문입니다.

curValue와 oldValue를 Objects.equals의 인자로 넘기는 것을 보면 알 수 있습니다. 정리하면, TreeMap은 키 값의 순서를 가지고 동작하는 자료구조입니다. 따라서, compare 클래스를 넣거나 compareTo를 override 하면 동작합니다. value의 경우 equals가 구현되어있지 않으면 동작하지 않는 기능이 있다는 것 정도만 알아가시면 됩니다.

java stream maptoobj 함수에 대해 알아봅시다.

코딩강아지 — Tue, 9 May 2023 23:57:19 +0900

java stream에서 maptoobj 함수는 중간 연산이라 되어 있습니다. 길이 n짜리 배열을 obj object n개로 채우려고 합니다. obj 클래스에는 int 자료형만 하나 있고, 우리는 이 n개의 obj가 깊은 복사가 되어야 해요. 이걸 stream을 써서 할 때, Intstream의 range 메서드와, maptoObj를 사용하면 손쉽게 처리할 수 있습니다.

mapToObj 메서드를 봅시다. Intstream 뿐만이 아니라, Longstream과 DoubleStream에도 있습니다. 설명을 보면, 스트림으로부터 해당 함수를 적용한 객체 값들의 stream을 반환한다고 되어 있어요. 즉 입력 스트림으로부터 무언가를 받아서, 새로운 결과 가지고 있는 스트림으로 변환합니다.

n개의 크기를 가진 리스트에 깊은 복사한 Obj 오브젝트 n개를 채워야 한다고 해 볼게요. 그러면 단순하게 List를 새로 생성해서 Obj 객체를 추가해도 됩니다. 그런데, 조금 더 생각해 보면 아래와 같은 로직을 생각할 수 있습니다.

1부터 5까지 있는 stream이 있어요. 이것을 아래와 같이 변환시키면 어떨까요?

하나의 원소가 새로운 new Obj(3)으로 바뀌는 것입니다. mapToXXX류가 이러한 역할을 수행합니다. 이 경우 IntStream의 원소들을 다른 obj로 변환시키는 apply 작업을 수행했습니다.

그림으로 그리면 이런 상황인 셈입니다. 즉, mapToXXX는 스트림의 요소들을 다른 요소로 바꾼 새로운 스트림을 돌려줍니다. 위 그림에서는 x를 new Obj(3)으로 바꾸었습니다. 따라서, 1 2 3 4 5로 이루어져 있던 것을 new Obj(3), ... , new Obj(3)으로 대체하게 됩니다.

이제 문제 상황을 다시 봅시다. 저는 객체 Obj n개가 채워진 ArrayList를 원합니다. 객체 n개는 깊은 복사가 되어야 하고요. 객체 Obj는 int 필드 하나만 주어져 있습니다. n = 4라고 해 보겠습니다.

당연하게도, setter가 있기 때문에, 불변 객체가 아닙니다. 어떻게 하면 될까요? 로직부터 설계해 봅시다. 일단, 이전에 배웠던 range는 1부터 n까지의 순서를 가지는 stream을 생성합니다. 고로, IntStream.range(1, 5)를 먼저 수행합니다.

다음에, 해당 stream을 토대로 Obj로 이루어진 스트림을 새로 생성합니다. mapToObj로요.

그러면, 1부터 5까지 순서로 이루어진 Stream이 new Obj(3)으로 이루어진 4개의 객체로 이루어 집니다. 참고로 각 원소별로 apply가 별개로 동작하므로 매번 새로운 객체가 생기게 됩니다.

toList로 Stream을 List로 변환합니다.

최종 코드는 20 ~ 21번째 줄에 나와 있습니다. 23번째 줄에 list의 0번째 원소의 x 값을 2로 바꾸어 봅시다. 만약에 저 객체들이 모두 얕은 복사가 되었다면, 모두 2가 출력되었을 겁니다.

그런데 3이 출력되었습니다. 이유는 toList가 호출될 때 mapToObj에 있는 apply인 x -> new Obj(3)가 실행되기 때문입니다. 각각의 element에 대해 적용되기 때문에 별개의 새로운 오브젝트 Obj가 생성됩니다.

git 상대 참조와 ^, ~에 대해 알아봅시다.

코딩강아지 — Sat, 6 May 2023 23:59:08 +0900

git에서는 ~와 ^와 같은 것들이 있습니다. 그리고 상대 참조도 있어요. 특정 커밋을 기준으로 참조한다는 의미입니다. 이들을 간단하게 알아보고 ~와 ^의 차이도 같이 알아보겠습니다.

실습을 할 git graph는 아래와 같이 되어 있습니다.

뭔가 복잡해 보이는데요. 천천히 따라가 봅시다. HEAD는 커밋 e4621faa를 가리키고 있어요.

먼저, ~n은 기준이 되는 커밋으로부터, first parent로 가는 연산을 n번 하는 것입니다. 이게 무슨 말인가? HEAD는 e4621faa라고 했습니다. 해당 커밋으로부터 --first-parent들을 뽑아 보겠습니다.

e4621.., 15a595.., 431c9.. 이 순서대로 나와 있어요. 여기서 주목해야 할 점은 e4621.. 커밋의 부모는 1개가 아니라 2개입니다. 하나는 15a595.. 이고 다른 하나는 b6c69.. 이거였습니다. 이를 그림으로 표현해 보겠습니다.

현재 HEAD가 가리키고 있는 커밋의 부모들을 표현해 보았습니다. 검은 실선으로 되어 있는 것은 1번째 부모인 15a59를 의미합니다. 다음에, 빨간색 점선으로 되어 있는 것은 e4621의 2번째 부모를 의미합니다. e4621로부터 1번째 부모로 1번 이동하면, 15a59가 됩니다. 이게 HEAD~1인 셈입니다. 기준이 되는 커밋이 어떤 것이였나요? HEAD였습니다. 그리고 이것은 HEAD^와도 같습니다. 즉, 현재 커밋으로부터 1번째 부모는 HEAD^인 셈입니다.

그러면 HEAD~2는 어떻게 해석하면 될까요? HEAD의 1번째 부모의 1번째 부모를 의미합니다. HEAD는 e4621이였습니다. 이것의 1번째 부모는 15a59였습니다. 이 커밋의 1번째 부모는 431c9였습니다. 따라서, HEAD~2는 431c9가 됩니다.

그러면 ^{n}은 무엇을 의미할까요? 이는 기준 커밋의 n번째 부모를 의미합니다. 대표적으로 머지가 된 경우, 부모가 여러 개일 수 있는데, 부모가 여러 개 나올 수 있습니다. 부모 여러 개 중에 하나로 이동하기 위해서는 필요하겠습니다.

git rev-parse HEAD^2를 입력했더니, b6c69..가 나왔습니다. 이 말은, e4621..의 2번째 부모가 b6c69.. 라는 의미입니다.

그림으로 도식화 시키면 위와 같이 됩니다. 여기서 질문. HEAD^2^2는 무엇을 의미할까요? HEAD의 2번째 부모의 2번째 부모를 의미합니다.

HEAD의 2번째 부모는 b6c69.. 였으니, 이 커밋의 2번째 부모를 찾으면 됩니다. git rev-parse b6c6994^2를 해 보니, 97d30..이 나오는군요.

b6c69..의 부모도 2개밖에 없고, b6c69..의 2번째 부모가 97d30.. 이니 1번째 부모는 50791이 됩니다. HEAD는 e4621 커밋입니다. 그리고, HEAD^2^2는 HEAD의 2번째 부모의 2번째 부모입니다. 위 그림에서는 빨간색 화살표만 따라가면 나옵니다. 따라서, 커밋 HEAD^2^2는 97d30..이 됩니다.

그러면 HEAD^2^2~1은 어떤 커밋이 될까요?

다시 커밋 그림을 봅시다. HEAD^2^2가 97d30.. 이라고 했습니다. ~1은 기준 커밋으로부터 1번째 부모로 1번 이동하라는 의미입니다. 1번째 부모로 이동해 볼까요?

431c9로부터 뻗어나왔습니다. 따라서 431c9가 됩니다.

즉, ~n은 기준 커밋으로부터 1번째 부모로 n번 이동하라는 말이고, ^{n}은 기준 커밋으로부터 n번째 부모로 이동하라는 의미가 되겠습니다.

git rev-parse 명령어로 현재 커밋 hash를 확인해 봅시다.

코딩강아지 — Fri, 5 May 2023 23:53:36 +0900

git에는 rev-parse라는 명령어가 있습니다. 이 명령어로 현재 커밋의 hash라던지, 특정 커밋의 hash 등을 얻어올 수 있습니다. 예를 들자면, 현재 브랜치의 커밋에서 5개 전에 있는 commit의 hash라던지, 다른 branch의 head에서 5개 전의 커밋 hash 등도 얻어올 수 있습니다. 상대 참조의 개념을 이용하면 이런 것들은 어렵지 않게 할 수 있습니다. 이건 보너스로 실습하면서 알아봅시다.

git graph는 위와 같습니다. 현재 브랜치의 head의 커밋 hash을 얻어오고 싶습니다.

그러면 단순히 git rev-parse HEAD 이렇게 입력해 주시면 됩니다. 현재 제 커밋은 cef083c.. 임을 볼 수 있어요.

해당 커밋에서, main.txt가 최초로 추가되었습니다. 현재 제 작업 디렉토리에 main.txt가 있음을 봐야 겠네요.

있으니까 문제가 없네요.

제가 많이 하는 git reset HEAD^에서 HEAD^는 어떤 커밋을 의미할까요? git rev-parse HEAD^를 입력해 보겠습니다. 그러면, 6abb가 나오게 됩니다.

Merge branch 'test3'이 있었고, 해당 커밋 다음이 cef08.. 입니다. cef08..은 현재 HEAD가 가리키고 있는 커밋이니, 이전 커밋임을 알 수 있습니다. git graph로도 알 수 있는 사실이지만, cef08..의 부모 커밋은 6abb4.. 입니다.

cef0 입장에서 보면 1번째 부모는 6abb인 셈입니다.

그런데, git rev-parse HEAD^2를 하면 어떤가요? 이는 HEAD의 2번째 부모를 의미합니다. 그림으로 그리면 어떤 상황인가? 이런 상황입니다.

빨간 점선을 따라가게 되는데, 커밋이 없는 상황입니다. unknown이니 에러를 뱉겠군요.

이제 git rev-parse HEAD~2를 입력해 보겠습니다.

HEAD~2는 현재 HEAD로부터 부모의 부모 커밋을 의미합니다. 그런데 깃 그래프를 보겠습니다.

HEAD로부터 1개 전 커밋이 6abb..인데, 2개 전 커밋은 b6c..가 될 수도 있고, 15a5..가 될 수 있는 상황입니다. 그림으로 그리면 이런 상황입니다.

6abb..의 first parent는 어느 쪽일까요? git log 6abb.. --first-parent로 1번째 parent만 찾아보겠습니다.

b6c6.. 이네요. 이는 git log 명령어에 --first-parent 옵션을 주면 알 수 있습니다.

pillow transpose 함수와 mode에 대해 알아봅시다.

코딩강아지 — Thu, 4 May 2023 00:37:01 +0900

pillow의 transpose는 이미지를 선이나 점을 기준으로 뒤집을 때에도 쓰이고, 회전시킬 때에도 쓰입니다. 간단하게 실습해 보겠습니다.

먼저 원본 이미지는 LEFT입니다. transpose 함수는 리터럴 0부터 6까지를 넘기게 됩니다. 이들 각각은 회전시키거나, 뒤집을 방법을 의미해요.

left.jpeg를 엽니다. 다음에 img.transpose(0)을 한 다음에, save를 합니다. 그러면, 0번 방법으로 뒤집거나 회전시키게 됩니다. 0번 방법은 무엇일까요?

기존 이미지에서 무엇이 바뀌었나요? 좌우 대칭이 되어 버렸습니다. FLIP_LEFT_RIGHT입니다. 기존 LEFT 그림에서 L 앞에 세로선을 기준으로 뒤집었다고 생각하시면 되겠습니다.

다음 1번은 어떤가요? 상하가 뒤집혀 버렸습니다. LEFT 밑에 가로선을 기준으로 뒤집어 버린 것입니다. FILP_TOP_BOTTOM인 셈입니다.

다음 2, 3, 4번은 이미지를 회전하는 것입니다.

left_2입니다. 2번 방법입니다. 기존 이미지에서 윈도우 뷰어 프로그램을 이용해서 시계 방향으로 90도 3번 회전시켰습니다. 공식 문서에서는 ROTATE_90인데요. 원본 사진을 반시계 방향으로 90도 회전시킨 것을 의미합니다.

그러면 ROTATE_180은 무엇을 의미할까요? 원본 사진을 180도 회전시킨 것입니다. 고로 위 사진과 같이 됩니다.

4번 방법은 원본 사진을 반시계 방향으로 270도 회전시킨 것입니다. 이 말은 시계 방향으로 90도 회전시킨 것과 같습니다.

5번과 6번은 각각 TRANSPOSE와 TRANSVERSE입니다. 이 둘은 또 무엇인가? 먼저 TRANSPOSE는 (x, y)였던 것이 (y, x)로 변환이 일어나는 것입니다. (1, 2)와 (2, 1), 그리고 (-3, 2)와 (2, -3)은 y=x축 대칭입니다.

간단하게 L자 그림을 그려 보겠습니다. y=x는 1번, 4번 영역을 지나가고 있어요. 따라서 2번 영역과 y=x 대칭인 것은 3번입니다. 따라서 L을 TRANSPOSE 시키면 ㄱ이 되게 됩니다.

다음에, L...을 y=x축 대칭을 시켜 봅시다. 그러면 1행에 ㄱ, 2행에 . , ... 요런 패턴으로 나오게 됩니다. 대칭 축을 그리면 아래와 같습니다.

이해가 가실려나요?

따라서 이런 그림이 나오게 됩니다. 그런데, 이것을 조금 더 쉽게 이해하는 방법이 있습니다.

왼쪽 그림은 LEFT 그림을 좌우로 filp 한 것입니다. 오른쪽 그림은 좌우로 filp한 그림을 반시계 방향으로 90도 회전시킨 것입니다. 오른쪽 그림과 5번 모드가 정확하게 일치함을 볼 수 있어요.

6번 모드는 TRANSVERSE 모드입니다. 이 모드는 아래 선을 기준으로 대칭이동 시킨 것입니다. 그러면 아래와 같이 나올 겁니다.

이것도 직관적으로 이해하기 쉽지 않네요. 좌우로 filp한 이미지를 90도 시계 방향으로 돌려 보겠습니다.

좌측이 좌우로 filp 된 것이고, 우측이 좌우로 filp 된 것을 90도 시계 방향으로 회전시킨 것입니다. 정확히 6번 모드와 똑같이 나옴을 볼 수 있습니다.

mode와 filp, 대칭 관계를 정리하면 위와 같습니다. 여기서 5번은 TRANSPOSE를, 6번은 TRANSVERSE를 의미합니다.

pillow exif_transpose 함수로 이미지를 돌려놓아 봅시다.

코딩강아지 — Tue, 2 May 2023 23:28:50 +0900

안녕하세요. exif 때문에 이미지가 이상하게 돌아가는 경우가 있습니다. 이 때 (회전 정보가 있는) exif 정보를 제거하는 방법을 알아보겠습니다.

먼저, 실습에 사용될 이미지는 여기에서 구할 수 있습니다. 제 pycharm에서 down-mirrored.jpg를 열어보겠습니다. down-mirrored.jpg입니다.

아래쪽으로 뒤집어진 모양을 하고 있습니다. 원래 모양은 DOWN이 위로 오고, 다음 줄에 MIRRORED가 돠야 합니다. 회전 정보가 어딘가에 들어가 있음을 알 수 있어요.

우리는 간단하게 이미지를 열고, exif_transpose 함수를 사용해 봅시다.

이 함수의 설명을 보면, EXIF orientation tag가 있다면, 그 정보를 바탕으로 변환된 새로운 사진을 돌려주고, 원래 정보는 제거해 버립니다. 이 함수의 내부를 잠깐 보겠습니다.

보시면, image.getexif() 함수에서 exif 정보를 얻어옵니다. 296, 282, 531, 274, 283과 같은 이상한 수들이 있어요. 이 수들에 대한 정보는 여기에서 얻을 수 있습니다. 이 중 274는 행과 열로 표시되는 이미지 방향이라는 것을 알 수 있습니다.

이를 바탕으로 transpose 함수를 호출해서, 새로운 이미지를 만듭니다.

결과는 DOWN MIRRORED로 제대로 보임을 알 수 있습니다.

이번에는 다른 이미지입니다. 좌우로 뒤집힌 모양을 하고 있어요.

exif 정보에는 어떤 것이 담겨 있을까요? orientation이 2임을 주목해 주세요. FLIP_LEFT_RIGHT인데요. 좌우가 바뀐 모양임을 의미합니다. exif_transpose 함수로 exif에 들어있는 orientation 정보를 바탕으로 회전을 시킵니다. 그리고, exif 정보를 제거해 보겠습니다.

up-mirrored.jpg를 연 다음에, exif_transpose를 호출한 다음에 img.save를 합니다.

그러면 좌우로 뒤집힌 사진이 원래대로 돌아옴을 볼 수 있습니다.

파이썬 tempfile의 임시 디렉터리 위치와 바꾸는 방법을 알아봅시다.

코딩강아지 — Sun, 30 Apr 2023 23:57:04 +0900

파이썬의 fastapi에서 Uploadfile은 파일이 엄청나게 클 때 어떻게 관리할까요? 10기가 정도 된다고 했을 때요. UploadFile의 file이 SpooledTemporaryFile을 사용한다고 하였습니다. 파일이 매우 클 때에는 디스크의 임시 파일이 저장되는 위치에 저장하게 됩니 이 글에서는 fastapi에 대해서는 다루지 않습니다. 다만, fastapi가 매우 큰 파일에 대해서 어떻게 다루고 있고, 이를 보기 위해서 임시 파일이 저장되는 위치와, 임시 파일이 저장되는 경로를 바꾸는 방법 정도만 가이드 합니다.

먼저, tempfile은 임시 파일을 의미합니다. gettempdir()은 임시 파일이 저장되는 위치를 가지고 옵니다.

Users의 chokw의 AppData의 Local의 Temp에 있네요. 이 위치에 들어가 보겠습니다.

그러면, 이상한 폴더들과 파일들이 잔뜩 있음을 알 수 있어요. 이제 8기가 정도 되는 큰 파일을 업로드 해 보겠습니다.

docs에 접속해서, 큰 파일 하나를 올려봅시다. 그리고 임시 파일에 새로 올라오는 파일의 속성을 보도록 하겠습니다.

tmp66r8xk6b라는 파일이 올라왔음을 알 수 있어요. 1.26기가나 되네요. 이를 메모리에 올릴 수 없다면 디스크에 올려놓고 조금씩 불러오는 전략을 쓴다는 것을 간파할 수 있어요.

fastapi의 main.py를 봅시다. tempfile을 import 한 뒤에, tempfile.tempdir을 "tmp"로 바꿔보겠습니다.

대충 요래 바꿉니다. 그러면 어떤 일이 일어날까요? 큰 파일을 업로드 할 때 임시 파일이 있는 경로가 아니라, 제가 설정한 프로젝트 루트 경로의 tmp 경로에 올라가게 됩니다.

tmp7tduibwa라는 이름으로 올라갔음을 볼 수 있어요. 여기서 정리하면, 임시 파일이 올라가는 경로를 바꾸려면, tempfile을 import 한 다음에, tempfile.tempdir을 원하는 경로로 바꿔버리면 됩니다.

반면에, gh5.pdf는 작은 파일입니다. 205k밖에 되지 않습니다.

이 경우, 파일이 올라오지 않음을 볼 수 있어요. 이로 미루어 보았을 때, SpooledTemporaryFile은 파일의 크기가 작을 때에는 따로 임시 파일을 만들지 않고 메모리에서 관리한다는 것을 알 수 있어요. 그렇지 않으면 아래와 같이 관리한다는 것을 알 수 있어요.

임시 파일을 저장한다.

몇 바이트의 크기만큼 읽어와서 메모리에 로드한다. 생각보다 이 방식은 자주 보이니 알아두시면 좋을 지도 모르겠네요.

fastapi 파일 사이즈 제한을 검사하는 방법을 알아봅시다.

코딩강아지 — Sat, 29 Apr 2023 23:01:56 +0900

fastapi에서 UploadFile을 이용하여 파일을 올리고 제한 검사를 서버단에서 하는 방법을 알아보겠습니다.

먼저 로컬에 파일을 올릴 것이므로 app.mount로 미디어 경로도 같이 설정해 줍니다. 참고로 요래 설정하면, 루트 프로젝트에 media 디렉토리가 있어야 동작합니다.

다음에 upload_file 함수입니다. file의 size 체크를 해서 2메가가 넘어가는 파일은 거부합니다. 그러기 위해, await file.read()를 호출한 다음에, content의 길이가 2메가가 넘는 경우 거부를 합니다. 그렇지 않으면, path 위치에 content를 씁니다.

다음에, get_user 함수입니다. 함수 이름이 이상한 거 같은 건 넘어갑시다. /upload를 부르면 2메가 이하인 파일을 업로드 하게 됩니다.

프로그램은 제대로 잘 동작할 겁니다. 문제는, 3기가가 넘는 파일을 올릴 때입니다. content의 길이가 2메가가 넘기 때문에 거부가 됩니다만, 문제는 메모리가 치솟아 버린다는 것입니다.

실제로, 작업 관리자 창에서 확인해 보면, python이 3695.7메가까지 올라가는 것을 확인할 수 있습니다.

메모리를 봅시다. 상당히 급격한 변화가 있었는데요. 이는 제가 중간에 프로그램을 종료해 버렸기 때문입니다. 3기가에 비해서 2메가는 매우 작습니다. 그런데 왜 3기가가 넘는 메모리가 사용되었을까요? 비밀은 content = await file.read()에 있습니다. 파일의 전체 내용을 가지고 온 다음에, 크기를 검사하다 보니 벌어진 사단입니다.

그러면 어떻게 해야 할까요?

서버단에서 처리하는 방법은 chunk 단위로 읽어버리는 것입니다. file.file의 정체는 SpooledTemporaryFile입니다. 이를 조금씩 읽어들입니다. 이 과정에서 읽은 누적 크기가 제한을 넘어가게 되면 에러를 뱉어버리면 됩니다.

해당 코드는 위와 같습니다. real은 0입니다. 그리고, 파일을 읽어낼 때 마다, chunk의 크기를 더합니다. 크기는 파일의 끝까지 갈 때 까지 계속 누적이 되므로, 2메가가 넘어가면 중간에 에러가 나오게 됩니다.

다음에, 22번째 줄 file.seek(0)이 중요합니다. 이것은 파일의 맨 처음으로 가는 것입니다. 이것이 왜 필요할까요? file.file을 돌면서 chunk를 읽어버릴 때 마다 파일을 계속 읽어버리기 때문입니다.

예를 들어 이 상태에서 일정 부분만큼 파일을 읽었다고 해 보겠습니다.

회색 부분만큼만큼 읽었기 때문에, 다음에 await file.read()를 하면 노란색 부분밖에 읽지 않습니다.

처음 부분으로 이동하게 되면 온전히 전체 파일을 읽게 되기 때문에, 정상적으로 수행됩니다.

메모리 또한 급격하게 늘어났다가 줄어들지 않음을 확인할 수 있습니다.

fastapi background tasks를 간단하게 알아봅시다.

코딩강아지 — Tue, 25 Apr 2023 23:58:52 +0900

fastapi에서 backgroundtask는 다소 무거운 작업을 back ground로 돌릴 때 씁니다. 예를 들자면 이메일을 보내는 시간은 다소 깁니다. 그래서, 그냥 task에 등록만 해서 background에서 돌고 있는 무언가가 처리하게 하고, 204 response를 떨어트리는 식으로 쓰게 됩니다. 매우 무거운 작업은 다른 방식을 고려하는 편이 좋습니다.

main.py 입니다. 천천히 보겠습니다.

write_notification입니다. 다른 건 없고요. ti초동안 sleep를 하게 됩니다. 중간에, 프로세스의 id와 thread id를 찍습니다. 이는 background task가 실행될 때 마다 어떤 것이 달라지는지 trace 하기 위함입니다. async def가 아니라, 그냥 def로 호출하였는데요. 왜 그렇게 호출하였는지는 밑에서 후술하겠습니다.

다음에 get_user입니다. GET /c/{ti}로 호출할 수 있습니다. /docs로 들어가서 swagger로 해당 api를 동시에 여러번 호출해 보겠습니다.

end에 떨어지는 부분을 주목해 주세요. 뒤에 숫자가 다릅니다. 이 말인 즉슨, thread id가 모두 다르다는 것입니다. 이를 그림으로 그려보면 아래와 같습니다.

write_notification 함수는 background_task로 돌았는데, 같은 프로세스에 있는 별개의 thread에서 돌았다. async로 설정하면 어떻게 되는지는 잘 실험해 보실 것이라 믿습니다.

간단하게 BackgroundTasks와 BackgroundTask 부분을 보겠습니다. BackgroundTasks는 list를 하나 들고 있습니다. 이는, task를 모아놓는 역할을 합니다. 다음에, __call__ 함수에서, self.tasks를 모두 돌면서 await task()를 하게 됩니다. 이 과정에서 어떤 부분이 호출될까요?

이 함수가 호출됩니다. async가 아니면, run_in_threadpool. 즉 쓰레드 풀 안에서 task를 돌려버립니다.

그림을 그리면 이런 모습입니다. 저는 아무런 옵션도 주지 않았으니, 들어온 순서대로 task가 실행되게 됩니다. 한 쓰레드에 1번, 2번 task가 들어온 경우, 1번이 실행된 후에 2번이 실행됩니다. 이 말인 즉슨, task 1이 실행되다가 예외가 발생해 버린 경우, task 2는 실행되지 못한다는 의미입니다. 정말 그럴까요?

task 2개는 위와 같습니다. write_notification은 Exception을 떨어트립니다. 다음에 notification 2는 ti를 출력합니다.

write_notification task를 등록한 다음에, write_notification_2를 등록하였습니다.

실행 결과를 볼까요? Exception이 떨어지고 그 다음 ti를 출력하는 task는 실행되지 않았음을 알 수 있습니다.

리눅스 잡거나 무시될 수 없는 signal에 대해 알아봅시다.

코딩강아지 — Sun, 23 Apr 2023 23:59:17 +0900

리눅스 시스템 프로그래밍이나, 혹은 c언어 시간에 signal은 잠깐 접해볼 기회가 있을 겁니다. 이 글에서는 signal 함수를 쓰고 있습니다만, 실습으로만 쓰고 있다는 점 참고 부탁드립니다. sigaction 쓰세요.

signal이 들어오면 처리하는 방법은 몇 가지가 있습니다. 그냥 아무 로직도 태우지 않거나, 무시하거나, 혹은 해당 시그널이 발생했을 때 잡아서 특정 루틴을 수행하던지. 그런데, 이 중 몇 가지 예외가 있는데요. 무시하거나 잡을 수 없는 signal이 두 개 있어요. SIGKILL과 SIGSTOP. 이 둘을 간단하게 보도록 하겠습니다.

먼저, SIGINT, SIGKILL, SIGSTOP, SIGTSTP 이렇게 4개의 signal 번호를 얻어봅시다.

제 시스템에서는 2, 9, 19, 20번입니다.

signal 함수로, 특정 시그널이 발생했을 때 잡을 수 있습니다. signal의 2번째 인자는 해당 시그널이 발생했을 때, 어떤 루틴을 수행할 것인지에 대해 정의를 합니다. 여기에서는 그냥 signal만 찍고 있음을 알 수 있습니다. 저는 SIGINT, SIGKILL, SIGSTOP 시그널을 수신했을 때, sig_hand를 호출하게끔 하였습니다.

이제 test3을 실행시켜 보겠습니다. 그리고 ps -aux로 test3이 돌고 있는 프로세스의 pid 6676을 얻어올 수 있었습니다.

2번 시그널을 날려 보겠습니다.

그랬더니 test3을 실행시킨 프로세스에서 2가 출력됩니다. 제 시스템에서 SIGINT는 2번이고, SIGINT 시그널을 잡았기 때문에 핸들러가 수행된 셈입니다.

이제 9번 시그널을 보내보겠습니다. 어떻게 될까요?

9가 출력될 줄 알았는데, 그대로 종료되어 버립니다. 이는, 9번은 잡거나 무시될 수 없는 신호 중 하나이기 때문입니다.

19번 SIGSTOP을 날려 보겠습니다.

제가 SIGSTOP을 잡는다고 핸들러에 등록했음에도 불구하고 19가 출력되지 않고, suspended가 출력되었음을 알 수 있습니다. 추가로 비슷한 시그널 중에 SIGTSTP가 있습니다. 이것도 시그널을 보내면 suspend가 되게 하긴 합니다만 무슨 차이가 있을까요?

SIGTSTP를 잡아보았습니다.

test3을 실행시키고, ctrl+Z를 눌러보겠습니다. 그러면, 20이 계속 출력됨을 볼 수 있어요. SIGSTOP과 다르게 잡아버릴 수 있는 시그널입니다. fg에서 bg로 바꾸는 방법 중에 ctrl+Z를 누른 다음에 bg %N을 하라고 했었는데요. 제 리눅스 운영체제에서는, SIGTSTP를 발생시키고 bg %N을 입력하라는 말이였던 셈입니다.

git rebase 명령어를 쓸 때 쓸 수 있는 --onto 옵션에 대해 알아봅시다.

코딩강아지 — Fri, 21 Apr 2023 08:00:14 +0900

안녕하세요. 이번 시간에는 git rebase를 할 때 쓸 수 있는 --onto 옵션에 대해 배워보겠습니다.

현재 깃 branch가 다음과 같다고 해 보겠습니다. 2.txt add 라는 커밋에서부터 test 브랜치가 분기했습니다. 그런데, test bug.. 가 있어요. test 브랜치에 실수로 bug가 많은 커밋을 push해 버렸습니다. 이 commit으로부터 test2가 분기했습니다. test2는 1.txt에 무언가를 append 한 모양입니다.

master에는 2.txt에 무언가를 추가했습니다.

test bug.. 입니다. 3.txt에 It is bug feature라는 것이 추가되었습니다.

다음에 1.txt에 무언가를 추가한 커밋입니다. test2에 붙어 있었습니다. 4와 5가 추가되었습니다.

다음에, master에 2.txt에 append를 한 커밋입니다. 4, 5가 추가되었습니다. git rebase master test2 명령어를 입력해 보겠습니다.

그러면 깃 그래프가 요래 그려집니다. 이 상황을 그림으로 그려보면 아래와 같습니다.

원래 요래 된 상태였습니다. git rebase master test2를 하면, master의 head 뒤에 test2의 커밋들이 붙어버립니다. 여기까지는 알겠는데요. 어떤 커밋들이 붙을까요? reflog로 확인해 보겠습니다.

pick test bug..와 pick append 1.txt가 보이네요. pick이 된 커밋들은, 회색으로 표시해 보겠습니다.

회색 부분이 master의 head 뒤에 붙어버린 것입니다. 이는 분기가 된 2.txt add로부터 master의 변경 사항과 회색으로 칠한 부분의 변경 사항이 같지 않기 때문입니다. test bug..와 append 1.txt가 같이 끌려 나와서 아래와 같이 커밋이 생성될 수 밖에 없을 겁니다.

중요한 것은 test bug.. 까지 그대로 들어갔다는 것입니다.

다시 이 상황으로 돌아오겠습니다.

우리는 test bug..를 빼고 단순하게 test2만의 변경 사항을 master의 뒤에 붙일 수 없을까요? 현재는 test 뒤에 붙은 상태입니다만, 이를 master로 옮기고 싶습니다.

그럴려면 git rebase --onto master test test2를 입력하시면 됩니다. 이렇게 하면 어떻게 될까요?

파란색으로 칠한 부분만 master의 뒤에 붙게 됩니다. 즉 주황색으로 칠해진 test의 커밋은 master의 뒤에 붙지 않습니다. test로부터 뻗어나온 test2의 커밋들이 붙게 됩니다.

즉, test2가 더 이상 test에 의존적이지 않게 됩니다.

예제를 하나 더 드리겠습니다. 깃 그래프가 요래 됩니다. 2.txt add로부터 master와 test가 뻗어나옵니다. 다음에 test로부터 test2가 뻗어나오고, test2로부터 test3이 뻗어나옵니다.

이제 git rebase --onto master test test3을 입력하였습니다. 결과는 어떻게 나올까요? 일단, master의 뒤에 붙는 것은 맞습니다. 어느 커밋을 pick 하는지가 문제입니다.

커밋은 이렇습니다. 일단, test3은 test2로부터 뻗어나왔고, test2는 test로부터 뻗어나왔기 때문에, test3은 test로부터 뻗어나왔습니다. 고로, test로부터 뻗어나온 군청색과 보라색의 커밋이 master 뒤에 붙게 됩니다.

정말 그런지 볼까요? master 뒤에 append 1.txt와 add 4.txt가 붙었음을 볼 수 있습니다. 즉, git rebase --onto A B C인 경우, A 뒤에 B로부터 뻗어나온 C의 커밋들이 붙게 됩니다.

git rebase 명령어에 대해 간단하게 알아봅시다.

코딩강아지 — Thu, 20 Apr 2023 00:35:14 +0900

안녕하세요. 이번 시간에는 기준을 재지정 할 때 쓰일 수 있는 git rebase에 대해 간단하게 알아보겠습니다.

먼저 test branch에는 227fdfa3과 185dfc5c 이 두 브랜치가 쌓여 있습니다.

227fd..는 1.txt에 1, 2, 3이 추가된 것입니다.

185df...는 2.txt에 1, 2, 3이 추가된 것입니다.

다음에 master 브랜치에 있는 d2bc7e9a는 1, 3이 3.txt에 추가된 것입니다.

git rebase test를 입력해 보겠습니다.

그랬더니, 요래 바뀌어 버렸습니다. 어떻게 수행된 것일까요? master인 상태에서 git rebase test를 입력하였습니다. 문서를 보면, 현재 branch가 topic인 경우, git rebase master와 git rebase master topic이 동일하게 수행된다고 되어 있습니다. 지금 제 current branch는 master였고, 저는 git rebase test를 했습니다. 따라서, 현재 branch가 master였던 제 상황에서 git rebase test와 git rebase test master는 동일한 일을 수행합니다.

어떻게 수행되는가? 위 그림을 보면, test의 head에 3.txt add라는 커밋이 쌓인 것에다가 master의 3.txt add 커밋이 다시 쌓였음을 알 수 있습니다.

그림으로 그리자면 원래는 이런 상황이였습니다. 중간에 튀어 나온 3.txt add가 있습니다. master에만 적용된 것입니다. 이 상황이였는데, 아래와 같은 상황이 되어버린 셈입니다.

master의 3.txt add가 붙는 기준점이 2.txt add 커밋으로 변경되었습니다. test의 HEAD과 같습니다. 즉 test의 HEAD 다음에 3.txt add가 붙어버렸습니다. 기준점이 2.txt add이기 때문입니다. 그 다음에 3.txt add 커밋이 붙고 해당 커밋을 master가 가르킵니다.

다시 이 상황으로 돌아옵시다. 위 그림과 같은 상황에서, git rebase master test 명령을 입력했다면 어떻게 되었을까요?

한 번 입력해 봅시다. 그러면 updated refs/heads/test 메세지가 뜹니다. 이 경우, master의 head가 기준점이 되고, 그 기준점으로부터 1.txt add와 2.txt add가 붙습니다. 그 다음에, 마지막 커밋인 2.txt add에 test가 붙습니다.

그림으로 그리면 이런 상황이 되겠습니다. 정말 그렇게 변했는지 커밋 그래프를 확인해 보겠습니다.

master는 3.txt add까지 반영되어 있고, 다음 1.txt add와 2.txt add는 test에서 추가로 쌓인 커밋들이네요. git checkout test를 실행해서 3.txt가 잘 있나 보겠습니다.

1, 3이 적혀있는 3.txt가 잘 있음을 확인할 수 있습니다. 이는 test의 기준점이 main commit이 아니라, master의 3.txt add였기 때문이 가능합니다. 해당 커밋이 1, 3이 적혀져 있는 3.txt가 추가되는 것이기 때문입니다. 다음 시간에 -onto 옵션을 알아보도록 하겠습니다.

filezilla 로 파일 업로드 다운로드 하는 방법을 알아봅시다.

코딩강아지 — Mon, 17 Apr 2023 23:58:46 +0900

안녕하세요. 이번 시간에는 filezilla를 이용해서 파일을 업로드 하고 다운로드 하는 방법을 알아보겠습니다.

저는 ssh에 접속하기 위해서 mobaxterm을 많이 쓰는 편입니다. 이것은 sftp도 제공되기 때문에, 라이센스 문제만 없다면 써도 무난합니다. 그렇지 않은 경우 생각보다 유용하게 써먹을 수 있어서 공유해 보겠습니다. 파일 - 사이트 관리자를 눌러보겠습니다.

먼저, 프로토콜은 SFTP를 선택합니다. ftp와 다른 점은 Secure가 붙어서 암호화 되어 전송된다는 것입니다. 그 말인 즉슨, 평문으로 전송하지 않고 암호화 해서 전송한다는 의미가 되겠습니다.

다음, 호스트는 ip 주소를 적습니다. ec2로 접속하려면 ec2 접속 사이트를 적어주면 됩니다. 다음, 로그온 유형입니다.

저는 비밀번호로 제 집에 있는 서버에 접속할 것이므로, 비밀번호 묻기를 선택하겠습니다. 키 파일이 있는 경우 키 파일을 선택해 준 다음에 키 파일을 넣어주시면 됩니다.

저는 비밀번호로 접속하려고 합니다. 제 서버의 ip 주소를 보기 위해 ifconfig 명령어를 입력해 주었습니다. 172.30.1.3이니까 이 주소를 그대로 쓰면 되겠네요. 이렇게 사이트를 만들고 나면 아래와 같이 접속하면 됩니다.

서버 3개 있는 아이콘 밑에 드랍 다운 버튼을 누르시면 사이트가 있습니다. 여기서, 접속할 사이트를 선택하시면 됩니다.

물론 빠른 연결을 할 수도 있습니다. 비밀번호를 입력해서 sftp로 연결한다면, sftp://ip 주소와 사용자명, 비밀번호를 입력해서 연결하면 됩니다.

인증 정보가 올바르다면 로컬 사이트와 함께, 오른쪽 탭에는 리모트 사이트가 뜨게 됩니다. 리모트는 원격이라는 뜻입니다. 제 입장에서는 파일을 올리고 다운로드 받는 서버를 의미합니다.

리모트 사이트 옆에 있는 /ftpuser_home은 현재 내가 원격의 ftpuser_home 디렉토리를 보고 있다는 의미입니다. 여기에 파일 하나를 올려보겠습니다.

gh_hide.jpg를 우클릭 한 다음, 업로드(U)를 눌러보겠습니다.

ftpuser_home에 gh_hide.jpg가 올라갔음을 볼 수 있습니다.

서버에 들어가서, 해당 디렉토리에 접근해 보니 정말로 gh_hide.jpg가 올라갔음을 알 수 있습니다. 당연하게도, 폴더 업로드가 됩니다.

클라이언트의 D: 폴더에 파일을 다운로드 받고 싶습니다. 그러면 로컬 사이트를 D:를 보게 만듭니다. D:를 선택하면 되겠네요. 그러면, 현재 제 로컬은 로컬의 D: 디렉토리를 보고 있습니다.

다음 리모트에 있는 파일을 클릭한 다음에 다운로드를 눌러보겠습니다.

몇 초 후에, 다운로드가 되게 됩니다. D: 폴더에 가 보니, gh_hide.jpg가 잘 들어왔음을 확인할 수 있습니다. 폴더도 다운로드가 되니 잘 이용하면 좋겠습니다.

git merge squash에 대해 알아봅시다.

코딩강아지 — Sun, 16 Apr 2023 01:20:32 +0900

안녕하세요. 이번 시간에는 git merge squash에 대해 간단하게 알아보고 실습해 보겠습니다.

현재, 깃 그래프는 위와 같아요. main commit가 master의 head입니다. 여기로부터 분기되어 test add와 test2 add라는 커밋이 들어갔는데요. 이 부분이 test 브랜치에 있는 commit입니다. 이제, 우리는 이런 상황을 생각해 보겠습니다. feature test를 개발했고, 테스트가 잘 되어서 merge하려는 상황입니다.

먼저, test add의 커밋 hash는 f7ca322.. 입니다. test.txt가 추가되었다고 하는군요. 어떤 내용이 추가되었는지 보겠습니다.

test.txt에 1과 2가 추가되었습니다.

다음 test2 add에는 test2.txt가 추가되었습니다. 커밋 hash는 f42e420입니다. 어떤 내용이 추가되었는지 보겠습니다.

역시 test2.txt에 1, 2가 추가되었습니다. test 브랜치에서 추가된 기능을 요약하면, test.txt와 test2.txt에 1과 2, 이렇게 2개의 줄이 추가되었다는 점이겠군요.

이제, git merge test --squash로 머지해 보겠습니다. test를 main에 merge를 하는데, --squash를 한다는 의미입니다. test에는 커밋 2개가 쌓여 있었는데요. 어떻게 머지가 되는지 보겠습니다.

test.txt와 test2.txt에 변경 사항이 있는, 커밋 hash가 923bf.. 인 커밋이 main에 추가됩니다. 즉, test에 test feature를 개발하기 위한 커밋이 t1, t2가 있었어요. 이 부분을 main에 머지했을 때, t1과 t2가 반영된 또 다른 t3'이 생성됨을 알 수 있어요. 즉 t1과 t2가 t3'으로 되었음을 알 수 있어요. 합쳐진 셈입니다.

해당 커밋에 test.txt와 test2.txt가 어떻게 변했는지 보겠습니다.

먼저 test.txt입니다. 1과 2가 추가되었습니다.

다음 test2.txt입니다. 역시 1과 2가 추가되었음을 알 수 있습니다.

리눅스 bg fg 전환 방법을 알아봅시다.

코딩강아지 — Fri, 14 Apr 2023 00:22:11 +0900

리눅스에는 foreground process, background process가 있습니다. foreground process를 백그라운드로 돌게, background process를 foreground로 돌게 바꾸는 방법을 알아봅시다.

먼저, foreground process입니다. sleep 100을 치면, 해당 terminal에서 100초동안 멈춰 있어요. 여기까지 정리해 봅시다. 제가 sleep 100을 터미널 tty1에서 입력하였습니다. 그러면, tty1과 sleep 100을 실행시킨 프로세스는 연결되어 있고, 100초가 지날 때 까지 유저와 커뮤니케이션을 하게 됩니다.

뒤에 &를 붙이면 어떻게 될까요? sleep 100 &을 했는데도, 멈춰 있지 않습니다. sleep 100을 백그라운드로 실행시켰다고 생각하면 편합니다.

요래 그려지겠네요. 정리하면 뒤에 &을 붙여서 실행하면 백그라운드 프로세스로 돌아간다. 입니다. 제가 sleep 100 &을 했기 때문에 터미널 tty의 뒤에서 돌아가고 있는 셈입니다. 데몬하고는 구분지어야 하는데요. 이건 기회 되면 한 번 정리해 보겠습니다.

이제 sleep 100을 한 상태에서 ctrl Z를 입력해 봅시다. 그러면, suspend 상태가 되면서 제어권이 터미널로 넘어오게 됩니다. 이를 간단하게 도식화 해서 그려보면 아래와 같습니다.

여기까지 별로 어렵지 않아요. 즉, foreground 프로세스가 실행되었을 때, ctrl + z를 누르면 suspend 상태가 된다. 정도만 기억하시면 됩니다. 혹은 signal을 보낼 수도 있습니다.

ps -aux | grep sleep을 쳐서 sleep을 실행시킨 프로세스를 찾습니다. 보니까 9116이네요. kill -19 9116 (sigstop 시그널)을 날려 보겠습니다.

그러면 sleep 프로세스가 signal 때문에 suspend 되었음을 볼 수 있어요.

이제 jobs를 보면 1번 job이 sleep 100이 잡혀있음을 볼 수 있어요. bg %1을 입력해 보겠습니다.

그러면 suspend 된 프로세스가 백그라운드로 실행됩니다. 이 경우에는 done까지 같이 출력되었는데요. 아마도 suspend를 시킨 지 너무 오래 되어서 그러지 않았을까 싶네요. 여기까지 정리해 봅시다.

별로 어렵지 않지요? ctrl+z를 눌러도 되고, SIGSTOP을 보내도 됩니다. 둘의 차이점은 잡거나 무시될 수 있는 시그널이냐, 그렇지 않냐입니다.

이제 background 프로세스를 foreground 프로세스로 돌게끔 만들어 봅시다.

jobs -l을 입력해 보겠습니다. 그러면, 작업들의 리스트와 pid가 나옵니다. 저는 이 중에 2번 job을 suspend 시킬 겁니다.

그럴려면 단순히 19번 signal, 혹은 stop signal을 9761번 process에게 넘겨주면 됩니다.

혹은 fg %N으로 N번 job을 foreground process로 바로 전환할 수도 있습니다. 여기까지 정리하면 아래와 같습니다.

redis 패턴 키 삭제하는 방법을 알아봅시다.

코딩강아지 — Mon, 10 Apr 2023 23:00:31 +0900

redis에서 특정 패턴을 가지는 키를 모두 삭제하는 방법이 없을까요? xargs를 이용하면 가능합니다.

먼저 키 값이 h1:1, h1:2, h1:3, h1:4, h1:5인 것을 넣어보겠습니다.

다음에 keys *를 입력하면 모든 키가 나옵니다. h1:2, h1:1, h1:3, h1:4, h1:5가 있습니다. 상당히 많은 키가 있는 경우에, 이들을 빠르게 삭제하고 싶은데요. redis에서는 패턴 삭제를 지원하지 않습니다. 대신에, 키를 삭제하는 연산과 특정 패턴을 가지는 키들을 보는 연산을 지원해 줍니다. 이를 이용해 봅시다.

keys h1:*는 h1:으로 시작하는 패턴의 키들을 모두 얻어옵니다. h1:2, h1:1, h1:3, h1:4, h1:5가 모두 해당 패턴애 match가 되니까 출력되겠네요.

shell에서 redis-cli keys "h1:*"를 입력하셔도 동일한 결과가 나오게 됩니다.

h1:2라는 키를 제거하기 위해 redis-cli del h1:2를 입력하였습니다. 그랬더니 1개의 키가 제거되었습니다.

결국 redis-cli keys 명령어와 redis-cli del 명령어를 잘 이용하면 된다는 결론을 얻었습니다.

xargs 명령어는 이 글에서도 설명했다 시피, 출력값을 command line의 인자로 넘겨주게 됩니다.

redis-cli keys "h1:*" | xargs redis-cli del 명령어는 redis에서 h1:* 패턴을 가지는 키들을 제거하게 됩니다. 이게 어떻게 일어나는지 간단하게 도식화 시켜 보겠습니다. 먼저, redis-cli keys "h1:*"를 하면, 아래와 같은 결과가 나올 겁니다.

이 결과들이 xargs의 input으로 들어가게 됩니다.

그러면 이것은 어떻게 입력으로 받을까요? redis-cli del h1:1 h1:3 h1:4 h1:5로 받게 됩니다. 즉, redis-cli del의 arguments들로 받아버리게 됩니다. redis에서 del key1 key2 ... 는 key1 key2 ... 를 삭제하는 것입니다. 따라서, redis-cli keys "h1:*" | xargs redis-cli del은 "h1:*" 패턴을 가진 모든 키를 제거합니다.

이제 redis-cli을 켜서, keys h1:*을 입력해 봅시다. 그러면, empty array가 나옴을 확인할 수 있습니다.

python math의 lcm 함수에 대해 간단하게 알아봅시다.

코딩강아지 — Sun, 9 Apr 2023 23:57:17 +0900

python math의 lcm은 여러 정수의 최소 공배수를 구하기 위한 함수입니다.

1번째 예제입니다. 2와 3의 최소공배수를 구하라고 했습니다. 결과는 6이 나올 겁니다. 왜냐하면 2와 3의 공배수 중 최소인 것은 6이기 때문입니다.

여기까지는 별로 어렵지 않습니다. 당연한 것이니까요.

이제 0과 5의 최소 공배수를 구하려고 합니다. 어떻게 나올까요? 문서를 찾아보면, 하나라도 0이 있는 경우에 무조건 0이 나온다고 되어 있습니다. 따라서, 이 경우에는 0이 나오게 됩니다.

정말 그리 나오네요. 만약에 음수가 있으면 어떻게 될까요?

-4와 6의 최소공배수를 구하려고 합니다. 이 경우, -4의 multiple과 6의 multiple이면서 가장 값이 작은 positive integer를 돌려줍니다. multiple을 조금 더 넓게 볼 필요가 있는데요. y = ax이고, a와 x와 y가 integer라면 y는 x의 multiple이라고 합니다. 12는 -4의 multiple인가요?

네. 왜냐하면 12 = -4에 -3을 곱한 것이기 때문입니다. 그리고, -4, -3은 integer에 속합니다.

고로, -4와 6의 최소 공배수는 12라는 결과가 나옵니다. 여기까지는 쉽게 이해할 만한 내용입니다.

제가 출제했던 가희와 서울 지하철 1호선 문제는 구간 lcm을 잘 처리해야 하는 문제였습니다. 그런데, python의 math.lcm을 잘못 사용해서 overflow가 발생했던 경우가 조금 있었습니다. 일단, math.lcm의 경우 결과 값으로 얼마나 커지면 런타임 에러를 뱉어버릴까요?

간단하게 1과 10^9000의 최소공배수를 구해 봅시다.

그랬더니 어떻게 나오나요? 4300자리 수까지 출력 가능하다 되어 있어요. 이 제한을 물론 풀어버릴 수도 있어요.

3.11버전부터 추가된 sys의 set_max_str_digits로 풀어버리면 됩니다. 8번째 줄에 9005라고 넣었는데요. 9005자리의 수까지 제한을 풀어버리겠다는 의미입니다.

그러면 10^9000도 정상적으로 출력됨을 확인할 수 있습니다. 그런데 소수들 몇 개를 lcm 시켜버리면 상당히 큰 수가 나오게 됩니다. 2이상 5000 이하 소수들의 최소 공배수를 구해 보겠습니다. 그리고 제가 해당 문제에서 그러한 데이터를 세팅해 놓지 않았을 리가 없을 겁니다.

어떻게 해야 할까요? 이 문제의 경우, 최대 제한을 넘어가는 경우에 inf로 잘라버리면 됩니다. 예를 들어 1부터 5000까지 최소 공배수를 구해야 한다고 해 보겠습니다. 그러면, inf가 넘어가는 순간에 강제로 최소 공배수가 inf가 되게끔 조정해 주면 됩니다. 우리에게 중요한 정보는 특정 구간의 최소 공배수가 1 이상 100만 이하의 소수이냐입니다. 만약에 최소 공배수가 inf라면 이 범위를 초과하는 것이기 때문에, valid 하지 않다는 정보는 쉽게 파악이 가능합니다.

1부터 5000까지의 최소 공배수는 너무 크니까 1061109567로 처리해도 됩니다. 그렇게 해도 문제에서 요구하는 1 이상 100만 이하의 소수보다는 작습니다. 1061109567이 나왔다는 것은 이미 답이 100만을 초과했다는 것과 동치입니다.

python convert value to enum과 name to enum을 하는 방법을 알아봅시다.

코딩강아지 — Sat, 8 Apr 2023 23:47:31 +0900

안녕하세요. enum은 보통 상수값을 선언하고, 제약하기 위해서 많이 쓰게 됩니다. 이번 시간에는 그 중에, valie 값으로 대응되는 enum member를 얻어오는 방법과 name to enum을 하는 방법을 알아보겠습니다. 상당히 많이 쓰일 듯 하니 알아두면 좋을 듯 합니다.

그 전에 몇 가지 용어를 알아볼 거에요.

enum은 name과 value가 있어요. 5번째 줄을 보겠습니다. RED = "red"라고 되어 있어요. 여기서 우리는 RED를 name이라고 합니다. 그리고, 이 이름에 대응되는 값 "red"를 값이라 불러요.

8 ~ 9번째 줄은 Color.Red의 이름과 Color.Red의 value를 출력합니다.

각각 RED와 red가 출력되게 됩니다. 이 둘을 묶어놓은 것을 member라고 합니다. 즉, enum에서 member는 name과 value를 가지고 있다고 볼 수 있어요. 여기까지 정리해 봅시다.

어렵지 않지요?

이제 이 내용을 바탕으로 value를 enum member로 바꾸는 방법을 알아봅시다.

먼저 enum member는 3개가 있어요. RED, BLUE, ORANGE입니다.

먼저 value를 기준으로 값을 얻어오는 방법은 아래와 같이 불러오는 것입니다.

Color("red"). enum 클래스가 E라고 한다면, E(value)로 불러오면 됩니다. 그러면 value에 대응되는 member가 나오게 됩니다.

위 프로그램의 실행 결과는 Color.RED가 나옵니다. 이건 어떤 메소드를 호출할까요?

디버그를 쭉 따라가다 보면, enum.py의 __call__을 호출함을 볼 수 있습니다. 계속 따라 들어가면 __new__를 호출하게 됩니다.

cls._value2member_map_이라는 딕셔너리에서 값을 얻어오는데요. 이를 통해, value를 키 값으로, member를 value 값으로 하는 딕셔너리가 있어서, enum의 값이 매우 많아도 효율적으로 작동할 거라는 추측을 할 수 있습니다.

이제, name으로 member를 부르고 싶습니다. 이 때에는 어떻게 하면 될까요?

enum 클래스가 E라고 한다면, E["name"] 이렇게 부르면 됩니다. 위 예제는 Color["RED"]로 member를 호출하였는데요. 이러면, enum Color에서, 이름이 "RED"인 멤버를 부르게 됩니다.

내부적으로 __getitem__을 부르게 되고, _member_map_이라는 딕셔너리에서 값을 얻어오게 되므로, 이 역시 효율적인 연산이 됩니다.

java linkedhashmap removeeldestentry 메소드에 대해 알아봅시다.

코딩강아지 — Tue, 4 Apr 2023 02:16:05 +0900

가희배 5회 코딩테스트가 4월 2일에 열렸습니다. 제가 플레 이상으로 예측한 문제도 있었지만, 골드 정도로 예측했는데 실제로 까 보니 플레였던 문제가 있었습니다. 그 문제에 이어서 또 당한 셈인데요. 이 문제가 어려웠던 이유는 2가지가 있습니다. 카카오 기출 문제를 3개나 섞었다. 그리고, 이 문제에 jpop 이랑 kpop이 상당히 많이 들어가면서 지문 자체가 어마어마하게 길었다. 이 2가지가 있겠습니다. 이것은 가희와 코드도 마찬가지입니다.

후자는 사전 지식이 없으면 해석하는 데 시간이 구현시간보다 더 걸렸을거고 전자는 구현량이 생각보다 있었습니다.

문제에서 요구하는 것은 2가지입니다. lru, 가장 가까운 cache 찾기, 엄청나게 긴 지문과 이상하게 jpop과 kpop이 들어간 예제 해석. 이 중 lru 부분은 클래스로 따로 빼서 구현해야 겠다는 생각은 하셨을 겁니다. 그리고 Java의 Collection에는 LinkedHashMap이 있습니다.

여기서, accessOrder의 설명을 봅시다. ordering mode를 의미한다고 되어 있어요. 만약에 이 값이 true면 AfterNodeAccess, 즉 접근하고 난 후 노드 처리를 하는 메서드와, AfterNodeInsertion, 노드를 추가하고 난 후의 처리를 하는 메서드를 호출하게 됩니다. 이 클래스의 공식 문서를 뒤져가면서 찾아보면 removeEldestEntry 메서드가 있어요.

오늘은 이것을 볼 거에요.

요렇게 씁니다. LinkedHashMap을 생성할 때, accessOrder를 true로 주었습니다. capacity는 용량을 의미해요. 84번째 줄부터 86번째 줄까지를 보면 return size() > capacity; 를 볼 수 있는데요. 이건 또 무엇인가? 일단 size가 capacity보다 크면 true를 리턴합니다.

이 메서드가 true를 리턴하는가, false를 리턴하는가에 따라서 무언가에 쓰이게 될 겁니다.

AfterNodeInsertion을 봅시다. 그러면 evict이고 first가 NULL이 아니면서, removeEldestEntry(first)가 나옵니다. 이 3개의 조건이 참이면, 처음 원소를 remove 하게 됩니다. 그런데 저는 removeEldestEntry 메서드를 size() > capacity인지를 검사했단 말입니다.

이 메서드의 결과가 참이라면 가장 앞에 있는 원소를 제거해 버립니다. 그렇지 않으면 제거되지 않습니다. 여기서 정리할 수 있는 것은 2가지입니다. 아. Link로 연결된 것에서 head를 제거하는구나. 그러면 tail은 늦게 제거되겠구나. 그리고 특정 조건을 만족하면 꽉 찼으니, 제일 오래된 것을 제거하는 로직을 태우는데요. 그 기준을 정해주는 것이 removeEldestEntry가 되겠습니다.

하나 질문. 추가될 때에는 뒤에 tail에 추가되긴 할 텐데요.

tail에 추가되는 부분은 afterNodeInsertion에서 수행되지는 않습니다. 그러면 언제 수행되는가? putVal에서 newNode를 호출하는 시점에서 수행됩니다.

putVal 메소드를 잘 보면 newNode를 생성하는 부분이 있습니다. 이 부분을 디버그 하면서 따라들어가다 보면, LinkHashMap의 linkNodeLast 메서드를 부르고 있음을 알 수 있습니다.

로직을 보면, 그냥 맨 끝에 추가함을 알 수 있습니다. 그냥 tail에 새로 추가한 것을 넣어주고, 기존의 last와 p를 연결합니다.

노란색이 새로 추가된 것입니다.

그러면 접근을 한 것에 대해서는 어떻게 처리될까요? 당연하게도, 노드에 접근해서 맨 뒤로 밀어버릴 겁니다. e가 어디로 밀어지는지 보면 되겠는데요. 310번 줄에서 p = e, 가 있으므로, p가 어디로 가는지 보면 되겠습니다.

이것 저것 뚝딱한 다음에 tail = p가 되어 있습니다.

a, b, c로 연결된 상태에서 b에 접근했습니다. 그러면 어떻게 동작할까요? b를 제거합니다.

다음에 어떻게 해야 할까요? b를 tail에 추가하면 되겠네요.

이 과정을 수행하면 b가 맨 뒤로 가게 됩니다. 그림에서는 단일 링크드로 표현하였지만, 실제로는 before와 after가 있는 이중 링크드 리스트로 구현되어 있습니다. 결국, afterNodeXXX 메서드로 특정한 일을 수행한 후에 추가적으로 해야 할 일을 호출하게 됩니다. 추가를 할 때 용량이 꽉 찬 경우에 삭제하는 로직이 필요하고, 순서를 유지하는 것이 필요합니다. LinkedHashMap은 들어온 순서를 저장하고 있어요. 그리고 용량이 꽉 찬 경우에 삭제하기 위해서 removeEldestEntry를 구현했습니다.

이 둘을 잘 버무리면 복잡한 문제를 보다 단순화 시킬 수 있습니다.

파이썬 f string에서 bracket을 escape 하는 방법을 알아봅시다.

코딩강아지 — Fri, 31 Mar 2023 23:55:15 +0900

파이썬에 f string이 있습니다. 이 중 {는 replacement field라고 해서 특수한 문자로 취급합니다. 이것을 일반 문자처럼 취급하려면 어떻게 해야하는지 간단하게 알아보고 실습도 해 보겠습니다.

먼저 f string이 아닌 문자열입니다. 앞에 f가 붙지 않았어요. 그러면 {과 } 등은 일반 문자로 취급됩니다.

a{b}cde가 출력됨을 알 수 있어요.

그런데, 앞에 f가 붙었어요. 그 안에 {와 }가 있는데요. 이렇게 되면 replace가 되어 버려요. f"a{b}cde"는, {b} 대신에 b의 값이 들어가 버립니다. 그래서, 이 프로그램의 실제 결과는 a3cde가 출력되게 됩니다.

실행 결과는 위와 같습니다.

그러면 f string에서 {와 }를 일반 문자처럼 취급하려면 어떻게 해야 할까요? 즉, escape를 하고 싶습니다. 그럴려면 {의 경우 앞에 {를, }의 경우 앞에 }를 붙이면 됩니다. 즉 f-string에서 {{는 일반 문자 {를, }}는 일반 문자 }를 의미합니다.

실행 결과는 위와 같습니다.

이런 경우에는 어떻게 해야 할까요? 일일히 { 앞에 {를 붙여주고, } 앞에 }를 붙여야 할까요? replacement 필드가 없다면 그냥 " 앞에 있는 {를 빼도 됩니다만, 그렇지 않다면 상당히 까다로울 수 있습니다. pycharm에서는 {를 {{로, }를 }}로 바꿀 문자열 전체를 선택하고 ctrl+R을 누르면 됩니다.

이제, ctrl+R을 다시 누르겠습니다. 그러면, 내가 선택한 영역에 대해서만 찾게 됩니다.

{를 찾아서 {{로 바꿔 볼까요? Replacement에 요래 입력하고, Replace All을 누르겠습니다.

다음에 }를 찾아서 }}로 바꿉니다. 역시 Replace All을 눌러주면 됩니다.

실행 결과는 위와 같습니다. 이제 s1과 s2를 출력해 보겠습니다.

두 문자열이 서로 같음을 알 수 있습니다.

파이썬 max min 사용법과 default key 인자를 알아봅시다.

코딩강아지 — Thu, 30 Mar 2023 07:30:42 +0900

안녕하세요. 이번시간에는 파이썬 min, max에 대해 알아보겠습니다. 이것은 각 원소간에 <가 지원되면 가능합니다. 저는 보통 리스트에 있는 수들을 가지고 max, min값을 뽑을 때 상당히 많이 쓰곤 합니다.

기본적으로 max와 min은 빈 sequence에서는 동작하지 않습니다. 이 프로그램을 실행시켜 보겠습니다.

빈 리스트를 min의 인자로 넘겨주었습니다. 어떠한 값도 없으니 min이나 max를 적용하는 것은 불가능해 보입니다.

default는 이런 상황에서 유용하게 쓰일 수 있습니다. 똑같이 빈 리스트인 상황입니다. default값을 -1로 두었습니다.

이 경우, 예외가 떨어지는 것이 아니라 -1이 출력됩니다. 즉, sequence에 값이 없을 때 디폴트 값 k을 설정해 주면 빈 리스트를 넘겨주었을 때, k가 떨어지게 됩니다.

max는 list와 같은 sequence에서 가장 큰 값을 찾게 됩니다. 위 코드를 볼까요? 2, -1, 7이 들어 있는 리스트가 있어요. 최소값은 -1이고, 최댓값은 7이에요. 그러면 결과는 1번째 줄에 -1, 2번째 줄에는 7이 나올 겁니다.

여기까지는 그러려니 하고 넘어갈 수 있습니다. 그런데 조금 더 특이한 일을 하고 싶습니다. 바로 변환된 결과가 최소, 혹은 최대가 되는 x 값을 리턴하고 싶습니다. 이 때 key를 쓰면 됩니다.

key는 무엇일까요? key=lambda k: -k가 있는데요. 이를 편의상 함수라고 하겠습니다. 쉽게 말해, x에 대응되는 f(x)라고 해 볼게요. key로 함수 f를 주면, f(x)가 최소가 되는 x 값을 구해줍니다. 위 예제에서는요. lambda k: -k이기 때문에, f(x) = -x가 됩니다. x가 2, -1, 7인 경우에, f(x)의 값은 -2, 1, -7이 됩니다. f(x)의 최소값은 -7이 됩니다. 그럴려면 x가 7이 되어야 겠네요?

즉, 2, -1, 7이 있다면, f(x)를 최소가 되게 하는 것은 7이 되기 때문에 7이 리턴됩니다.

결과는 7이 나옵니다.

이번에는 리스트에 있는 수들 중 절댓값이 최소인 것을 구하고 싶습니다. 이건 또 어떻게 하면 될까요? 복잡하게 생각하지 않아도 됩니다. 그냥, lambda y: abs(y)를 넘겨주면 됩니다. 그러면 x를 넘겨주었을 때, f(x) = abs(x)가 됩니다. -2, 1, 7 중 절댓값이 최소인 것은 1이므로, 1이 리턴됩니다.

정말 그렇게 나오는군요

이건 어떨까요? 각 아이템들이 list입니다. lambda y: sum(y)입니다. 인풋은 list이네요? output은 sum(list)입니다. 리스트를 받으면, 함수 f는 리스트에 있는 수들의 합을 리턴해요. [-2, 0, 3]의 합은 1, [-1, 19]는 18, [3, 7]은 10, []은 0이니까 합이 가장 큰 [-1, 19]가 리턴되겠네요?

실행 결과는 위와 같습니다.

pytest coverage omit 옵션으로 report에 특정 파일의 결과를 제외해 봅시다.

코딩강아지 — Tue, 28 Mar 2023 07:20:38 +0900

pytest와 pytest-cov를 저는 같이 쓰는 편입니다. report를 할 때 굳이 coverage 측정이 필요 없는 것이 있을 텐데요. 이들을 제외하는 방법을 알아보겠습니다.

pytest는 7.2.2, coverage는 7.2.2, pytest-cov는 4.0.0 버전에서 실습하였습니다.

먼저, 프로젝트 request_ex의 구조입니다. pg1 패키지에 a.py가 있고, pg2 패키지에 b.py가 있습니다. 다음에 root에 main.py가 있고, .coveragerc가 있는데요. 이 .coveragerc는 coverage 관련 설정을 적어놓습니다.

main.py입니다. pg1.a로부터 feature_a를 import하고, pg2.b로부터 feature_b를 import 했네요. test_a에는, feature_a(1)과, feature_b(3)을 호출합니다. 다음에 pyest main.py --cov를 입력해 보겠습니다.

그랬더니, main.py, pg1/__init__.py, pg1/a.py, pg2/__init__.py, pg2/b.py의 커버리지가 출력됩니다. 토탈 coverage는 85%라고 출력되는군요. 어디서 cover를 깍아먹었는지 html 형식으로 report 해 보겠습니다.

프로젝트의 root 폴더에서 python main.py --cov --cov-report=html을 입력해 보겠습니다. 그러면, htmlcov라는 폴더가 하나 새로 생길 겁니다. index.html로 들어가 보겠습니다.

표 형식으로 Statements, missing, excluded가 나오는 것을 볼 수 있어요. Module에 있는 pg1/a.py를 클릭해서 들어가 봅시다.

그러면 missing이 보이는데요. feature_a(1)을 호출하였습니다. x > 1인 경우를 호출하지 않았기 때문에, 5번째 줄이 전혀 실행이 안 됩니다. 따라서, 1 missing이 뜨게 됩니다.

feature_b는 어떨까요? x가 3인 경우만 호출했기 때문에, x <= 1 조건에 걸리는 문장이 수행되지 않습니다. 1 missing입니다. 간단하게 요래 보시면 되겠습니다.

우리는 .coveragerc에서 [run]에 omit 옵션을 줄 수 있습니다. 잠깐. 여기서 omit은 제외하다라는 뜻이 있어요. 3번째 줄부터 5번째 줄까지 앞에 space 4개를 붙였습니다. 이 리스트들이 있는데요. pg1/**, main.py, *__init__.py가 있네요. 이 패턴들은 문서에 자세히 설명이 되어 있습니다만, 요약해서 설명드리겠습니다.

먼저 **는 몇 개의 directory도 상관이 없고, 심지어 아무 것도 없어도 됩니다. gitignore에서 **을 생각하시면 편하겠습니다. 다음에 *는 문자 0개 이상인 파일 이름인데요. /와 같은 디렉토리 구분자를 제외합니다. ?는 하나의 파일 문자를 의미합니다. 어떤 것이 제외되는지 보겠습니다.

먼저 pg1/**입니다. pg1 밑에 있는 .py 파일도 당연하게 제외됩니다. 다음에 *__init__.py가 있는데요. pg2 밑에 있는 __init__.py도 여기에 걸립니다. 따라서 pg2/__init__.py도 제외됩니다. 그리고 main.py는 root 디렉토리에 있는데요. main.py도 제외하라고 했으니, 이것도 제외됩니다.

다시 python main.py --cov --cov-report=html를 입력합니다. 다음에, htmlcov 밑에 있는 index.html에 들어가 보면, pg2/b.py만 report에 나옴을 볼 수 있습니다. 즉, .coveragerc에 [run] 옵션에 omit = 을 적어주고, 제외할 파일들의 패턴을 적어주면 됩니다.

notepad++에서 줄 번호로 찾아가는 방법을 알아봅시다.

코딩강아지 — Mon, 27 Mar 2023 07:00:23 +0900

notepad++에서 줄 번호 찾아가기 기능에 대해 알아보겠습니다.

line 수가 엄청난 파일을 다뤄야 하는 경우가 간혹 가다 있습니다. 예를 들자면 문제 출제할 때 입력 파일의 line 수가 100만줄이 넘어가는 경우도 매우 흔합니다.

이 데이터 파일은 100만줄이 넘네요. 32만번째 줄에 있는 것을 정확히 찾아가려면 어떻게 해야 할까요? 그냥 스크롤 바를 올려버리는 방법도 있습니다만, 일일히 줄 번호를 찾아가기 위해 스크롤바로 이동하면 상당한 인내가 필요할 것입니다. 찾기(S)를 누르면, 줄 찾아가기라는 메뉴가 있습니다. 이를 이용하면 매우 간단합니다.

줄 찾아가기의 단축키는 Ctrl+G입니다. 이것을 눌러 주겠습니다.

그러면 메뉴 선택창에 줄과 오프셋이 있습니다. 오프셋은 밑에서 후술하겠습니다. 이동할 줄 번호를 320000으로 입력해 보겠습니다.

그러면 정확히 32만번째 줄로 이동합니다. bylrzt[wed8이라는 내용이 있는 걸로 보아서는 이상한 제너레이트 알고리즘으로 데이터를 생성한 거 같습니다. notepad++에서 줄 번호를 찾아가기 위해서는 ctrl+G를 누르면 됩니다. 다음에, 줄을 선택하고, 이동할 줄 번호를 적고, 이동을 누르면 됩니다.

그런데, 오프셋으로 기능도 있습니다? 이 기능은 무엇을 하는 것일까요? 이동 가능한 마지막 줄 번호가 48047787인데요. 이 파일의 크기가 48047787byte임을 의미합니다. 14번째 오프셋으로 이동해 보겠습니다.

그러면 2번째 줄의 teg 앞에 오프셋이 이동했음을 볼 수 있습니다. 이는, 500000 500000이 13자이고, 13번째 offset이 1번째 줄의 끝을 가리키기 때문이에요. 1칸 더 이동하면, 2번째 줄의 시작을 가리킵니다. 즉, byte 단위로 이동하고 싶을 때 쓰면 됩니다.

이런 경우는 어떨까요? 한글과 영어가 섞여 있습니다. 인코딩 형식은 UTF-8입니다. 즉, 한글이 3byte이고 ascii가 1byte입니다. 이 경우, offset을 6으로 설정하면 어떻게 될까요? 한 번 그렇게 해 보겠습니다.

ctrl+G를 누른 다음에 오프셋을 선택합니다. 다음에 이동할 줄 번호를 6으로 적고 이동을 누르겠습니다.

그러면 는 앞에 커서가 이동합니다. 이는 가와 희가 UTF-8 인코딩에서는 3byte씩이나 차지하기 때문입니다. 즉, 오프셋은 byte 단위로 먹힌다는 것만 짚고 가셔도 되겠습니다.

파이썬 pytest stdout print 콘솔에 출력되게 해 봅시다.

코딩강아지 — Sat, 25 Mar 2023 23:59:32 +0900

어떤 프로그램을 테스트 할 때 pytest를 쓰는 편입니다. 이번 시간에는 print 문으로 출력한 것을 어떻게 콘솔로 볼 수 있는지 알아보겠습니다.

기본적으로 pytest는 capture 옵션을 fd로 받게 되어 있습니다. 이는 문서에도 나와 있는 부분이에요. 1번과 2번 데스크립터에 쓰여지는 내용, 즉 표준 출력과 오류가 모두 캡쳐되는 것이 default입니다. 실험을 하나 해 보겠습니다.

예제 프로그램 1번은 test_feature_a라는 함수를 만들었습니다. 간단하게 "1"을 표준 출력에 출력합니다.

그런데, 1이라는 것은 출력되지 않았습니다. 이는, 문서에 따르면 캡쳐되었기 때문입니다.

이것은 어떨까요? 1.txt에 1이라는 내용을 쓰는 프로그램입니다.

역시 테스트는 성공하였습니다.

1.txt에 쓰여진 내용 역시 1로 잘 출력되었습니다. 어? 이건 왜 그런 것일까요? 표준 입력, 출력이 아니였기 때문입니다. 이 말은, 파일에 출력하는 것은 문서에서 설명하는 1번, 2번 데스크립터와 와 별개의 fd를 사용했습니다. 고로, 캡쳐가 되지 않았고 파일에 출력되었던 것입니다.

그러면 어떻게 해야 print에 있는 내용이 콘솔에 출력될까요?

pytest의 --capture 옵션을 보면, fd, sys, no, tee-sys 이렇게 4개가 있다고 나와 있습니다. 디폴트가 fd입니다.

-s는 --capture=no의 짧은 버전입니다. 고로, 뒤에 -s를 붙여주면 캡쳐를 하지 않게 됩니다.

main.py는 메서드 test_a를 호출합니다. !를 print합니다.

-s 옵션을 붙여서 실행해 보겠습니다. 그러면 !이 떡하니 나오게 됩니다. 어떠한 캡쳐도 하지 않기 때문에, 표준 출력이나 에러 출력도 콘솔에 나오게 됩니다.