4월부터 기존에 다니던 회사에서 퇴사하고 나서 무얼 해볼까 고민을 많이 했다. python으로 개발을 배우기 시작하고, 빠르게 배워서 취업을 했었던 나로서는 처음부터 CS(computer science) 지식이 부족한 것 때문에 그것에 대한 갈망이 있어 CS 관련 강의를 들어보고 싶기도 했고, 금융권으로 취직을 하고 싶어 C++을 배워보고 싶었는데 그 발판으로 무얼 할까 고민을 했었다. 그 와중에 실무 프로그래밍 입문 강의를 접하게 되었고, "실무"에 적합한 지식을 가르치고 프로그래밍 기초를 가르친다는데에서 들어보기로 했다. 물론 처음엔 20만원 정도하는 강의라서 조금 비싸다고 생각했다. 강의를 다 들은 지금도 그 생각에 변함은 없지만 강의 내용은 굉장히 마음에 든다.

실무 프로그래밍 입문 C#

이 강좌가 마음에 들었던 이유는 사실 python으로 개발을 하면서 왜 이런 기능이 있는지에 대한 의문을 해소해 주었기 때문이다. 예를 들어 "class에서 decorator로 @staticmethod를 써보면서 그냥 instance로 만들고 method를 호출하는 거랑 뭐가 다른가?" 라던지 "한 번만 쓸 로직인데 이걸 가독성을 위해서 함수로 만들어야하나 말아야하나..." 등등 이런 의문을 예시를 들어주면서 해소시켜줘서 굉장히 마음에 들었다. 개인적으로 프로그래밍을 하면서 실수를 줄일 수 있는 방향으로 코드를 짜야 한다는 말이 마음에 와닿았다. 파이썬으로 웹 개발을 하다보면 깊이 생각을 안 하고 코드를 짜게 될 때가 있는데 워낙 무거운 프로그램이 아니다보니 그냥 실행시켜보고 오류나면 다시 고치는 걸 반복할 수 있기 때문이다. 이러다보면 내가 테스트해보지 않은 부분에서 오류/예외가 날 수도 있다는 생각에 불안불안한 마음 한편에 있었는데 이런 걸 방지하기 위해 실수를 줄일 수 있는 방향으로 코드를 짜는 방법을 가르쳐줘서 마음에 들었다.

결론적으로 가격 때문에 조금 망설여지긴 했지만 충분히 좋은 강의라고 생각한다. 그리고 좀 쉬면서 고민을 해보고 다음주에는 COMP1000: 소프트웨어 공학용 수학을 결제하고 들어볼 생각이다.

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

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

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

 

파이썬은 통과

python 실력평가는 통과!

 

;;

django는 불합격;

 

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

Linkedin 실력평가

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

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

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

00pen.tistory.com/91

 

TDD를 해야 하는 이유 #1

최근에 사수님께서 "이제 00도 테스트코드를 짜면서 코드를 짜보세요." 라고 하셨다. 그래서 당연히 넵 :) 이라고 답했다. 근데 "테스트코드를 먼저 짜면서 코드를 작성해보세요" 라고 하셨다. 나

00pen.tistory.com

저번에 글을 쓸 때는 자신만만하게 '이렇게이렇게 해야한다!' 라고 말했지만 막상 만들어보려니까 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를 다 만들고 하는 하는 것보다 빠르게 ( 그리고 잘 ) 만들고 오류가 난다면 바로바로 고쳐주는 게 더 효율적이라고 생각한다...

+ Recent posts