회사의 주인은 주주이지만 소속감을 느끼는 것은 직원이듯, 회사에서 작성한 코드의 주인은 회사이지만 그 코드에 애착을 느끼는 것은 개발자이다. 특히나 그 코드가 30대의 내 인생의 2년 3개월을 오롯이 바쳐서 만든 코드라면 더더욱.

개발자로 일을 하다 보면 코드 전달이라는 걸 하게 될 때가 있다. 일종의 인수인계인데, 최신 코드를 설명문과 함께 전달하고 필요에 따라 코드 설명회를 여는 과정이다. 코드를 전달받는 대상은 회사 내부의 다른 직원일 수도 있고 아니면 협력사가 될 수도 있다. 내가 얼마나 오랫동안 정성을 쏟아서 만든 코드이든 나에게는 가타부타할 권리가 없다. 회사에서 작성한 모든 코드는 회사의 것이고, 그걸 다 알고 계약서에 서명을 하고 입사했으니. 모든 절차를 마치고 태연한 척 '싱숭생숭해 할 필요 없어. 우리는 다 프로잖아?' 하는 허세 가득한 마음을 속으로 먹어 주면 모든 과정은 끝이 나게 된다.

그렇지만, 조선 시대에 유씨 부인이 바늘이 부러지자 슬픔을 금할 길이 없어 조침문(弔針文)을 지었다면, 나도 이제 내 손을 떠나가게 된 코드를 위해 글 한 토막은 쓸 수 있지 않을까. 유씨 부인은 17년 간 사용했던 바늘이 부러지는 순간 정신이 아득하고 마음을 빻아 내는 듯 해서 기색 혼절하였다고 하는데, 나야 그 정도는 아니지만 어쨌든 무언가 마음 속이 허한 것은 막을 길이 없다.

하지만 보내줄 땐 보내주어야 한다. 언제가 붙잡아야 할 때이고 언제가 보내주어야 할 때인지 사람은 본능적으로 안다. 보내주어야 할 때는 아쉬움이나 미련이 없게 충분히 슬퍼하고 애타한 뒤 깔끔하게 보내주어야 한다. 유씨 부인도 부러진 바늘을 대장간에 가져가면 왜 못 고치겠냐마는 '동네 장인에게 때이련들 어찌 능히 때일손가' 라며 마음을 정리하고 바늘을 고이 보내주었듯, 나도 이젠 코드를 보내줄 때가 되었다. 기실 바늘이나 코드는 자기가 어떻게 되었는지도 모른다. 괜히 바늘 주인이, 코드 개발자가 슬퍼하는 것이지. 아직 못다한 리팩토링이, 마음에 들지 않아서 바꾸고 싶었던 변수명이, 별도 브랜치에 작성까지 했으나 결국 메인에 머지되지 못한 커밋이 머릿속에, 그리고 마음 속에 자꾸 맴돈다. 이럴 줄 알았으면 수많은 코드 사이 어딘가에 이스터 에그 하나쯤 남겨놓을걸, 하는 큰 허전함을 뒤로 하고 마지막으로 아쉬우니 괜히 git pull 한 번 하고 너를 보낼게. 가서도 잘 컴파일되고 지내야 한다. 라이브러리 의존성 안 맞는다고 심술내면서 에러 내뱉지 말고. 건강히 착하게 잘 지내렴. 나는 이제 exit 할게. 안녕.

 

ImportError: cannot import name 'Self' from 'typing_extensions'

 

위와 같은 에러가 발생할 경우 다음 명령어를 사용하시면 해결됩니다.

 

pip install typing-extensions --upgrade

 

( 참조한 곳: https://github.com/python-openxml/python-docx/issues/1337 )

[EXIF Tag] 구글 포토에서 인식 가능하도록 날짜 정보 갱신하기

 

사진 및 동영상 파일의 EXIF 태그에는 여러 항목이 있는데, 구글 포토는 이 중 DateTimeOriginal 태그를 인식하여 사진이 찍힌 날짜를 추정합니다. 그래서 해당 태그가 아닌 다른 태그에 날짜가 저장된 파일의 경우 구글 포토에서 엉뚱한 날짜를 인식하는 경우가 종종 있습니다. 이를 방지하기 위해서는 exiftool 이라는 프로그램을 사용하여 다음과 같이 처리하면 됩니다. Exiftool은 https://exiftool.org/ 에서 다운받으실 수 있습니다.

 

아래 명령어를 순서대로 입력하면 됩니다. 명령어의 의미는 다음과 같습니다. 명령어 뒤의 /path/to/photos/ 는 사진이 있는 디렉토리의 경로입니다.

(1) DateTimeOriginal 태그가 없으면 FileModifyDate의 값을 DateTimeOriginal에 저장합니다.
(2) (1)의 내용을 K3G 파일에도 적용합니다.
(3) PNG 파일의 경우, DateTimeOriginal 태그가 있으면 그 값을 FileModifyDate에 저장합니다. 이 때 PNG 파일은 조금 특별해서, EXIF:DateTimeOriginal의 값을 가져와야 합니다.

(4)(5)(6) GIF, MP4, MOV 파일에 대해서, DateTimeOriginal 태그가 있으면 그 값을 FileModifyDate에 저장합니다.

 

exiftool -if 'not $DateTimeOriginal' -overwrite_original_in_place '-DateTimeOriginal<FileModifyDate' -r /path/to/photos/

exiftool -if 'not $DateTimeOriginal' -overwrite_original_in_place '-DateTimeOriginal<FileModifyDate' -r -ext k3g /path/to/photos/ 

exiftool -if '$DateTimeOriginal' -overwrite_original_in_place '-FileModifyDate<EXIF:DateTimeOriginal' -r -ext png /path/to/photos/ 

exiftool -if '$DateTimeOriginal' -overwrite_original_in_place '-FileModifyDate<DateTimeOriginal' -r -ext gif /path/to/photos/ 

exiftool -if '$DateTimeOriginal' -overwrite_original_in_place '-FileModifyDate<DateTimeOriginal' -r -ext mp4 /path/to/photos/ 

exiftool -if '$DateTimeOriginal' -overwrite_original_in_place '-FileModifyDate<DateTimeOriginal' -r -ext mov /path/to/photos/ 

 

 

한편 예전 핸드폰인 Cyon과 Optimus, 그리고 VK의 경우 추가로 해 주어야 하는 작업들이 있습니다. 먼저 Cyon과 Optimus의 경우 동영상 파일을 Cyon은 MP4, Optimus는 3GP로 저장하는데, 이 경우 MediaCreateDate 태그가 존재하기 때문에 그 값을 DateTimeOriginal과 FileModifyDate 으로 복사해오면 됩니다.

 

exiftool -if '$MediaCreateDate' -overwrite_original_in_place '-DateTimeOriginal<MediaCreateDate' -r -ext mp4 /path/to/photos/ 

exiftool -if '$MediaCreateDate' -overwrite_original_in_place '-FileModifyDate<MediaCreateDate' -r -ext mp4 /path/to/photos/ 

exiftool -if '$MediaCreateDate' -overwrite_original_in_place '-DateTimeOriginal<MediaCreateDate' -r -ext 3gp /path/to/photos/ 

exiftool -if '$MediaCreateDate' -overwrite_original_in_place '-FileModifyDate<MediaCreateDate' -r -ext 3gp /path/to/photos/ 



그리고 VK 핸드폰의 경우 FileModifyDate 태그조차 사진을 찍은 날짜가 아니라 파일을 컴퓨터에 저장한 날짜로 되어있기 때문에 다음과 같이 파일명에서 날짜를 추출해야 합니다.

 

rename s/P-/20/g ./*.*

exiftool -if 'not $DateTimeOriginal' -overwrite_original_in_place '-DateTimeOriginal<Filename' -r /path/to/photos/

exiftool -if '$DateTimeOriginal' -overwrite_original_in_place '-FileModifyDate<DateTimeOriginal' -r /path/to/photos/ 

 

 

[맥] 예기치 않은 오류가 발생했기 때문에 작업을 완료할 수 없습니다(오류 코드 -50).

 

[맥] 예기치 않은 오류가 발생했기 때문에 작업을 완료할 수 없습니다(오류 코드 -50).

 

이 오류는 파일 복사나 이동 중 파일명 혹은 파일 전체 경로가 너무 길어서 발생하는 오류입니다.

 

예를 들어 [ /Users/MyName/Desktop/안녕하세요_이_파일_이름이_너무_길어서_복사가_잘_안_될것_같지만_그래도_복사를_해_보려_하는데_과연_잘_될지_모르겠네요_복사가_잘_되도록_응원해주시면_정말로_감사하겠습니다.txt ] 같이 이름이 너무 긴 파일을 복사할 때 해당 오류가 발생할 수 있습니다.

 

파일명을 짧게 바꿔주시면 해결됩니다.

리눅스에서는 명령행에서 Home 키를 누르면 현재 명령의 맨 앞 글자로, End 키를 누르면 맨 뒤 글자로 커서를 옮길 수 있는데 맥에서는 그게 안 됩니다. 맥에서는 다음 단축키를 사용하면 됩니다. Ctrl은 컨트롤 키입니다 (커맨드 키가 아닙니다).

 

명령행 맨 앞 글자로 가기: Ctrl + A

명령행 맨 뒤 글자로 가기: Ctrl + E

f3을 사용하여 SD카드 및 USB 불량 여부 확인하기

 

집에서 사용하던 SD 카드가 있었는데 어느 순간부터 읽기가 잘 안 되었습니다. 수명이 다 하면 쓰기가 안 되는 경우는 예전에 본 적이 있는데 이번 SD 카드는 쓰기는 되고 읽기가 안 되었습니다. 어떻게 하면 불량 여부를 검사할 수 있을지 알아보다가 f3이라는 프로그램을 알게 되었습니다. f3은 Fight Flash Fraud의 약자로 "가짜 플래시 메모리와 싸우자" 정도의 뜻입니다. 공식 웹사이트는 https://fight-flash-fraud.readthedocs.io/ 이고 깃허브 주소는 https://github.com/AltraMayor/f3 입니다. 설치 방법은 웹사이트를 참조하시면 되는데, 리눅스나 맥 환경에서 설치 가능하고 윈도에서는 도커를 사용하면 됩니다.

 

설치가 끝나면 f3write를 통해 SD 카드 혹은 USB에 테스트용 데이터를 쓰고, 그 후 f3read를 통해 데이터를 잘 읽을 수 있는지 검사하면 됩니다. 먼저 f3write를 통해 다음과 같이 제 SD 카드를 검사하였습니다. /Volumes/my_sd_card 에는 SD 카드가 마운트 된 위치를 써 주시면 됩니다. 제 SD 카드는 32 GB 짜리이고 쓰기 속도는 평균 16.52 MB/s 라고 합니다. 일단 쓰기는 잘 되었습니다.

 

주의!! SD 카드에 테스트용 데이터를 쓰게 되므로 기존에 있던 데이터가 삭제될 수 있으니 기존 데이터를 일단 백업해놓은 뒤에 테스트하세요.

$ f3write /Volumes/my_sd_card
F3 write 8.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

Free space: 31.23 GB
Creating file 1.h2w ... OK!
Creating file 2.h2w ... OK!
Creating file 3.h2w ... OK!
Creating file 4.h2w ... OK!
Creating file 5.h2w ... OK!
Creating file 6.h2w ... OK!
Creating file 7.h2w ... OK!
Creating file 8.h2w ... OK!
Creating file 9.h2w ... OK!
Creating file 10.h2w ... OK!
Creating file 11.h2w ... OK!
Creating file 12.h2w ... OK!
Creating file 13.h2w ... OK!
Creating file 14.h2w ... OK!
Creating file 15.h2w ... OK!
Creating file 16.h2w ... OK!
Creating file 17.h2w ... OK!
Creating file 18.h2w ... OK!
Creating file 19.h2w ... OK!
Creating file 20.h2w ... OK!
Creating file 21.h2w ... OK!
Creating file 22.h2w ... OK!
Creating file 23.h2w ... OK!
Creating file 24.h2w ... OK!
Creating file 25.h2w ... OK!
Creating file 26.h2w ... OK!
Creating file 27.h2w ... OK!
Creating file 28.h2w ... OK!
Creating file 29.h2w ... OK!
Creating file 30.h2w ... OK!
Creating file 31.h2w ... OK!
Creating file 32.h2w ... OK!
Free space: 576.00 KB
Average writing speed: 16.52 MB/s
$

 

이제 읽기를 테스트할 차례입니다. 다음과 같이 f3read를 사용합니다. 왼쪽에서 오른쪽으로 ok / corrupted / changed / overwritten 이라고 되어 있는데, 정상 SD 카드라면 ok를 뺀 나머지 칸은 다 0이어야 합니다. 제 SD 카드의 경우는 7번째 구간까지는 정상적이나 8번째 구간부터 데이터가 망가져 있는 것을 볼 수 있습니다. 테스트가 끝나면 요약을 해 주는데 이 SD 카드는 전체 32 GB 중 7.48 GB 만 정상이고 나머지는 고장난 카드입니다. 버려야겠습니다.

$ f3read /Volumes/my_sd_card
F3 read 8.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097152/        0/      0/      0
Validating file 4.h2w ... 2097152/        0/      0/      0
Validating file 5.h2w ... 2097152/        0/      0/      0
Validating file 6.h2w ... 2097152/        0/      0/      0
Validating file 7.h2w ... 2097152/        0/      0/      0
Validating file 8.h2w ... 1009269/  1087883/      0/      0
Validating file 9.h2w ...       0/  2097152/      0/      0
Validating file 10.h2w ...       0/  2097152/      0/      0
Validating file 11.h2w ...       0/  2097152/      0/      0
Validating file 12.h2w ...       0/  2097152/      0/      0
Validating file 13.h2w ...       0/  2097152/      0/      0
Validating file 14.h2w ...       0/  2097152/      0/      0
Validating file 15.h2w ...       0/  2097152/      0/      0
Validating file 16.h2w ...    2880/  2094272/      0/      0
Validating file 17.h2w ...       0/  2097152/      0/      0
Validating file 18.h2w ...       0/  2097152/      0/      0
Validating file 19.h2w ...       0/  2097152/      0/      0
Validating file 20.h2w ...       0/  2097152/      0/      0
Validating file 21.h2w ...       0/  2097152/      0/      0
Validating file 22.h2w ...       0/  2097152/      0/      0
Validating file 23.h2w ...       0/  2097152/      0/      0
Validating file 24.h2w ...       0/  2097152/      0/      0
Validating file 25.h2w ...       0/  2097152/      0/      0
Validating file 26.h2w ...       0/  2097152/      0/      0
Validating file 27.h2w ...       0/  2097152/      0/      0
Validating file 28.h2w ...       0/  2097152/      0/      0
Validating file 29.h2w ...       0/  2097152/      0/      0
Validating file 30.h2w ...       0/  2097152/      0/      0
Validating file 31.h2w ...       0/  2097152/      0/      0
Validating file 32.h2w ...     640/   488961/      0/      0

  Data OK: 7.48 GB (15692853 sectors)
Data LOST: 23.75 GB (49808460 sectors)
	       Corrupted: 23.75 GB (49808460 sectors)
	Slightly changed: 0.00 Byte (0 sectors)
	     Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 0.00 Byte/s
$

 

유용한 내용이었으면 하트모양 공감을 눌러주세요!

[리눅스] The following packages have been kept back 원인과 해결 방법

 

우분투에서 sudo apt-get upgrade 실행 시 다음과 같은 메시지가 나오면서 업그레이드가 안 되는 경우가 종종 있습니다.

$ sudo apt-get upgrade

The following packages have been kept back:
  dkms ubuntu-advantage-tools
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.

$

 

이는 기존에 설치되어 있던 프로그램 중에서 의존성이 변경된 경우가 있어서 업그레이드를 위해서는 기존에 컴퓨터에 설치되어 있지 않던 프로그램을 새로 설치해야 할 경우에 나타나는 경고 메시지입니다. 위 예제의 경우 dkmsubuntu-advantage-tools를 업그레이드 하기 위해서는 기존에 없던 프로그램들을 새로 설치해야 하기 때문에 경고만 해 주고 업그레이드를 실행하지 않은 것입니다.

 

이런 경우 새롭게 필요한 프로그램들을 추가로 설치하면서 apt-get upgrade를 실행하려면 다음과 같이 --with-new-pkgs 옵션을 주면 됩니다. 말 그대로 '새로운 패키지와 함께 (with new packages)' 업그레이드를 진행하라는 옵션입니다. 해당 옵션을 주었더니 새롭게 dctrl-toolsubuntu-pro-client-l10n 두 종류의 프로그램을 설치하면서 dkmsubuntu-advantage-tools를 업그레이드하는 것을 볼 수 있습니다.

$ sudo apt-get --with-new-pkgs upgrade

Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  dctrl-tools ubuntu-pro-client-l10n
The following packages will be upgraded:
  dkms ubuntu-advantage-tools
2 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 349 kB of archives.
After this operation, 590 kB of additional disk space will be used.
Do you want to continue? [Y/n]

$

 

한편 이렇게까지 해도 안 되는 경우가 있다면 다음과 같이 aptitude를 설치하신 후에 aptitude를 통해 업그레이드를 진행하는 방법도 있습니다. 하지만 대부분 여기까지 오지 않아도 위의 방법으로 해결이 될 것입니다.

$ sudo apt-get install aptitude -y
$ sudo aptitude safe-upgrade

[이클립스] C/C++ Build Settings에 Tool Settings가 없을 경우 해결법

 

1. Properties -> C/C++ Build -> Settings에 가면 Tool Settings가 없는 경우가 있습니다.

2. 그럴 경우 Properties -> C/C++ Build로 가서 Makefile generation에 있는 Generate Makefiles automatically와 Expand Env. Variable Refs in Makefiles를 체크해주고 Apply and Close를 누릅니다.

3. 다시 Properties -> C/C++ Build -> Settings에 가면 Tool Settings가 나타나 있습니다.

 

 

 

 

분명 numpy를 설치했는데 파이썬에서 numpy를 사용하려 하면 다음과 같이 AttributeError: module 'numpy' has no attribute ... 하는 에러가 뜰 때가 있습니다.

import numpy as np

print(np.__version__)
# AttributeError: module 'numpy' has no attribute '__version__'

 

이는 numpy가 설치는 되었지만 시스템에서 파이썬 라이브러리로 제대로 연결이 안 되어서 그렇습니다. 이럴 경우 맥에서 homebrew를 사용할 때를 기준으로

brew link --overwrite numpy

 

를 실행해주면 문제가 해결됩니다.

 

참조한 곳: https://github.com/Homebrew/homebrew-core/issues/15698#issuecomment-315730732

일주일, 월화수목금 중에서 그 주의 최저가에 주식을 사고 싶다고 합시다. 특정 요일의 가격이 그 주의 최저가일 확률은 당연히 1/5이니 20%입니다. 그렇다면 우리는 그냥 20%의 확률로 찍으면서 기도매매법을 실천해야 하는 것일까요?

간단한 전략을 통해 이 확률을 두 배 넘게 올려 보도록 하겠습니다. 우리의 전략은 "첫 k일 동안은 시장을 살펴보고, 그 다음날부터는 그때까지 중에 가장 싼 가격이면 사자"입니다. 미지수는 x로 써도 되지만 요즘 이름 앞에 k를 붙이는 게 유행이라 k라고 했습니다. 어쨌든 예를 들어보면 다음과 같습니다.

k = 0 이라면? 첫 0일 동안은 시장을 살펴보고 그 다음날, 즉 월요일부터는 그때까지 중에 가장 싸면 삽니다. 말이 꼬여 있는데 당연히 월요일에는 비교할 가격이 없으니 그냥 그날 바로 사겠다는 말이 됩니다. 이건 찍는 것과 다를 게 없습니다. 따라서 k= 0일 때의 성공률은 월요일이 최저가일 확률인 20%입니다.

k = 1 이라면? 이제 좀 재미있어질 겁니다. 첫 1일 동안은 시장을 살펴봅니다. 즉 월요일에는 네이버 주식 창 새로고침만 합니다. 살 게 아니니 15분 늦게 가격이 떠도 상관없습니다. 그리고 다음날인 화요일부터 그때까지 중에 가격이 가장 싼 날이면 주식을 삽니다. 만약 화요일 가격이 월요일보다 싸면 화요일에 삽니다. 물론 수요일에 더 떨어질 수도 있지만 하여튼 우리 전략이 그렇습니다.

만약 화요일 가격이 월요일보다 높다면? 그러면 수요일로 넘어갑니다. 그리고 수요일 가격이 월화수 중 가장 낮다면 삽니다. 그런데 수요일도 월요일보다 비싸다면? 그러면 목요일로 넘어갑니다. 목요일 가격이 월화수목 중 가장 싸다면 삽니다. 목요일도 월요일보다 비싸다면? 금요일로 넘어갑니다. 만약 금요일도 월요일보다 비싸다면? 월요일이 최저가였네요. 그러면 못 사게 됩니다.

정리해 보면 k = 1 일 때,
* 알고 보니 월요일이 최저가 -> 실패 (0)
* 알고 보니 화요일이 최저가 -> 성공 (1)
* 알고 보니 수요일이 최저가 -> 월요일이 화요일보다 싸야만 성공 (1/2)
* 알고 보니 목요일이 최저가 -> 월요일이 화, 수보다 싸야만 성공 (1/3)
* 알고 보니 금요일이 최저가 -> 월요일이 화, 수, 목보다 싸야만 성공 (1/4)

각 요일이 최저가일 확률은 똑같이 20% 씩이니 그 값을 균등하게 곱해주면 k = 1 일 때 우리 전략의 성공 확률은

20% x (0 + 1 + 1/2 + 1/3 + 1/4)
= 20% x 25/12
= 41.67%

가 됩니다. 벌써 성공 확률이 두 배 넘게 올랐습니다!

k = 2일 때도 한 번 계산해 보도록 하겠습니다. 이 때는 월, 화까지는 기다려보고 수요일부터 살지 말지를 결정합니다. k = 2 라면,
* 알고 보니 월요일이 최저가 -> 실패 (0)
* 알고 보니 화요일이 최저가 -> 실패 (0)
* 알고 보니 수요일이 최저가 -> 성공 (1)
* 알고 보니 목요일이 최저가 -> 월, 화 중에 수요일보다 싼 날이 있어야 성공 (2/3)
* 알고 보니 금요일이 최저가 -> 월, 화 중에 수, 목보다 싼 날이 있어야 성공 (2/4)

그러면 k = 2일 때 우리의 성공 확률은

20% x (0 + 0 + 1 + 2/3 + 2/4)
= 20% x 26/12
= 43.33%

아까보다도 더 높아진 43.33%가 되었습니다!

같은 방식으로 계산하면 k = 3 일 때의 성공 확률은 20% x (0 + 0 + 0 + 1 + 3/4) = 20% x 7/4 = 35%, k = 4일 때는 20% x (0 + 0 + 0 + 0 + 1) = 20% 가 됩니다. k = 4라는 것은 금요일 하루에만 살 수 있다는 것이니 찍는 것과 성공 확률이 똑같겠지요.

정리해봅시다!
* 월요일부터 그때까지의 최저가면 산다: 성공확률 20%
* 화요일부터 그때까지의 최저가면 산다: 성공확률 41.67%
* 수요일부터 그때까지의 최저가면 산다: 성공확률 43.33%
* 목요일부터 그때까지의 최저가면 산다: 성공확률 35%
* 금요일부터 그때까지의 최저가면 산다: 성공확률 20%

즉 월, 화에는 시장을 지켜만 보다가 수요일부터 그 주의 그때까지의 최저가일 때 산다면 찍는 것에 비해 성공 확률이 배 이상 높은 43.33%가 됩니다! 단 이 경우 아예 못 살 확률이 40%이니 (월, 화 중에 최저가가 있는 경우), 주식을 좀 공격적으로 사 모으고 싶다면 화요일부터 이 전략을 적용하는 것도 좋겠습니다. 성공 확률은 41.67%로 비슷하고 주식을 아예 못 살 확률은 20% (월요일이 최저가인 경우)로 낮으니까요!

덧붙여 만약 주식을 팔고 싶은 경우라면 마찬가지 전략을 반대로, 즉 어느 날 이후에는 그때까지 중 가장 비싸다면 판다고 적용하면 되겠습니다.

자 그럼 성투하시기를 바라며 정성글은 춫천

- 끝 -

+ Recent posts