원래는 CI/CD보다도 AWS lambda와 CloudWatch를 통해 Cron job과 같은 걸 만들어보기 위해 개인 프로젝트를 시작해 보았습니다. 그런데 lambda 안의 코드의 관리를 어떻게 해야하나 고민하다가 요즘엔 container로 배포를 하는 것도 지원한다고 되어 있어서 이왕 하는거 AWS ECR(docker repo), lambda, Github Actions를 이용하여 CI/CD를 경험해 보아야 겠다고 생각하였습니다. 제가 예상(?)하는 CI/CD pipeline은 다음과 같습니다.

1. 코드는 github에서 관리, github actions를 이용해 master에 push할 때마다 CI를 진행

2. 무사히 테스트를 마치면 AWS ECR에 image를 빌드 후 push

3. lambda가 자동적으로 새 이미지를 가지고 코드를 돌리기 (이건 바로 되는지 테스트가 필요)

python에서 숫자 또는 문자열을 뽑아 왔는데 화폐 형식( 100,000,000 ) 이거나 숫자, 문자열을 화폐 형식으로 변환할 때

1. 화폐 형식 -> 숫자 or string

# delete thousand sperator
x = '100,000,000'
x = x.replace(',' , '')

2. int or float or string -> 화폐 형식

# insert thousands seperator
# if string, convert to int or float before insert thousands seperator
x = 1000000
x= f'{x:,}'

f-string이 참 편리하긴 하네요. 굿

json.decoder.jsondecodeerror expecting value line 1 column 1 (char 0)

Connection Error

python에서 파일을 불러오려다 보면 자주 보이는 오류입니다. pandas를 쓰면서 excel, csv를 불러올 때도 가끔 보이는 문제인데 encoding 문제일 수도 있습니다. 그런데 이번에 google drive api ( google spreadsheet api) 를 사용하던 도중 드라이브에 있는 파일을 불러오던 도중 이런 에러가 발생했습니다.  "분명 local에서 잘 읽어드린 파일인데 왜 그러지?" 라고 생각했는데 google spreadsheet api로 읽으려면 xlsx, csv 파일을 google Sheets로 한 번 변환해줘야 한다는 것을 알게 되었습니다.

보통 엑셀 파일을 드라이브에 올려 놓으면 파일 형식 그대로 들어와 파일을 열어보면 이렇게 .xlsx 형식이라고 보여주고 있습니다. 이 상태로는 python으로 잘 읽혀지지 않더라구요.

파일을 누르고 'Google Sheets로 저장' 이걸 눌러주면 Google Sheet 파일 형식으로 사본을 만들어 줍는데 그 파일을 열어보면 아래처럼 .xlsx, .xls 와 같은 표식이 지워져 있습니다.

이런 상태로 변하면 python에서도 Google api로 잘 불러와지네요... 이것 때문에 한 30분 정도는 헤멘듯...

링크드인앱을 깔아놓으면 누가 프로필을 봤다는 알람이 올 때가 있습니다. 대부분의 알람은 무음으로 설정해놔서 별 생각없이 지나가기 마련인데 가끔은 심심해서 링크드인앱에 들어가 보게 되네요. 근데 최근(?)에 보유기술의 실력을 평가해보는 기능이 생겼더라구요. 막 진지하게 본 것은 아니지만 궁금해서 보게 되었습니다.

python 실력평가는 통과!

django는 불합격;

둘 다 봐보니까 생각보다 호락호락하지는 않은 느낌이였습니다. 왜냐하면 문제가 15개 나오는데 반은 굉장히 기초적이여서 '쉬운데?'라고 생각할만 한 것들이 나오고, 반 정도는 꽤나 지엽적이고 코드나 구조를 깊게 파 본 사람만 알만한 문제가 나왔기 때문입니다. 예를 들어서 저는 django를 api 만드는데 많이 써서 template 관련해서는 잘 몰랐는데 template의 {% %} 요 태그 관련한 문제가 나와서 깜짝 놀랐습니다. python도 class의 method나 attribute 관련해서 묻는 간단한 질문이 있었다면 python이 돌아가는 작동원리를 묻는 문제도 있었습니다.

LinkedIn 실력평가에 대해 설명해 놓은 걸 보면 LinkedIn 온라인 클래스 전문가들이 문제를 냈기 때문에 신뢰할만하다고 하긴 하는데 아무데서나 볼 수 있어서 컨닝을 너무 쉽게 할 수 있는 허점이 있는게 아닌가 싶기도 합니다.

그리고 처음엔 시험을 볼 수 있는 기회가 두 번 주어지는데 탈락하면 3개월 이내에 동일한 시험을 볼 수 없게 된다고 합니다.

한 문제당 약 1~2분 정도 주는 것 같으니 굉장히 빠르게 볼 수 있어서 좋은 것 같고, python이나 django 말고도 html나 MS office들도 시험이 있을 정도로 많은 시험이 있으니 시간 남을 때 한 번 가볍게 풀어보시는 것도 추천드리고 싶습니다 :)

00pen.tistory.com/91

저번에 글을 쓸 때는 자신만만하게 '이렇게이렇게 해야한다!' 라고 말했지만 막상 만들어보려니까 assert문을 얼마나 넣어야할지 모르겠다는 생각이 들었다. 가장 작게 유닛테스트를 하는 것이 가장 기초이고, 유닛테스트부터 시작해봐야야 할 것 같다는 생각이 들었다.

먼저 가장 작게 하나의 함수나 메소드를 테스트하는 것이 가장 작은 유닛테스트가 될 것 같다. 기본적으로 내가 생각한 값이 나오는지 확인하고, 더 잘 확인하기 위해서는 어떤 범위가 나와야하는 함수라면 그 범위의 경계선도 체크하는 것도 중요하다고 알게 되었다.

그리고 최근에 Django를 이용해 api를 만드는 도중에 테스트 코드를 몇 개 짜봤는데 이런 프레임워크 안에는 단순히 python의 unittest를 사용하기엔 어려움이 있는 것 같고, 프레임워크 안에 test를 위해 만들어진 module이 있다면 그걸 사용하는 것이 맞는 것 같다. 왜냐하면 Django를 보았을 때 response를 테스트를 해야하는 것이 많은데 이걸 테스트하기 위해서 unittest를 쓰는 건 불가능하진 않지만 비효율적이고, django 또는 django rest framework 안의 test를 이용해야 client나 factory 이런 걸 활용해야 효율적으로 test 코드를 만들 수 있기 때문이다. 아래는 django, DRF의 test 코드 예시이다.

developer.mozilla.org/ko/docs/Learn/Server-side/Django/Testing

www.django-rest-framework.org/api-guide/testing/

이렇게 말하고 있지만 뭘 만드는데 완벽하게 유닛테스트 코드를 짜고, 만들기엔 그렇게 큰 프로젝트를 맡고 있지 않기 때문에 간단하게 한 class에 대해 setuplcass, teardownclass 넣고, 그 다음 모든 method에 대해 하나 또는 소수의 assert문만 넣어 끝까지 오류 없이 돌아가는지 정도만 test를 하고 있다.

근데 사실 절대 버그가 생기면 안되거나 여러 곳에서 참조하는 모듈이 아니라면 완벽하게 unittest를 다 만들고 하는 하는 것보다 빠르게 ( 그리고 잘 ) 만들고 오류가 난다면 바로바로 고쳐주는 게 더 효율적이라고 생각한다...