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를 다 만들고 하는 하는 것보다 빠르게 ( 그리고 잘 ) 만들고 오류가 난다면 바로바로 고쳐주는 게 더 효율적이라고 생각한다...

개발자로 취업을 하기로 마음 먹은 후 약 7개월이 지나고 파이썬 개발자로 취업을 하게 되었습니다. 컴퓨터 공학을 전공하신 분들에 비해서는 코드 몽키 수준이겠지만 항상 코드 아래서 컴퓨터가 어떻게 돌고 있는지 이해하기 위한 노력을 많이 하다보니 취업에 성공하지 않았나 생각이 듭니다.

아래 제가 밟아 왔던 과정을 자세히 설명하겠지만 결론부터 말하면 Django를 잘 공부하기 위해서는 에듀캐스트에 있는 리액트와 함께 장고 시작하기 (educast.com/course/web-dev/ZU53) 를 정말 추천하고 싶습니다. 22만원이라 좀 비싸다고 느끼긴 했지만 돈이 아깝지 않은 강의입니다.

먼저 저는 학부 때 배워본 건 파이썬 기초 밖에 없었지만 그걸 이용해서 프로젝트를 한 번 해보았으니 이걸 기반으로 갈고 닦으면 충분히 취업을 할 수 있을 거라고 생각했던 것 같습니다. 그래서 독학 아니면 학원을 다니는 선택지가 있었는데 공부를 시작할 당시에는 졸업을 하기 전이라 그냥 독학을 골랐습니다. 학원이 상당히 비싸다고 느끼기도 했고요... 그래서 처음 시작할 때는 nomad coder의 강의들을 들었습니다. (아래는 nomad coder에서 들었던 강의들 후기)

이전다음

01

아무튼 어느 정도 웹 개발이 이런거구나~ 라고 생각할 때쯤 컴퓨터 공학의 기초들의 필요성을 느꼈던 것 같습니다. 뿐만 아니라 몇몇 기업에서는 코딩테스트를 요구해서 먼저 자료구조와 알고리즘을 공부하기로 마음 먹었습니다. 그 때 당시에 막 파이썬 알고리즘 인터뷰라는 책이 나와서 그 책으로 공부했었습니다.

이 책을 통해 공부하면서 파이썬 내부의 standard library들을 알게 되었고, 굳이 다른 패키지를 깔지 않고도 아름다운 코드를 짤 수 있다는 것도 느끼고 magic method에 대해서도 공부하게 되었습니다. 그 후 배워온 Django 기술을 이용해 먼저 취업을 해서 실무 경험을 쌓아보고 싶다는 생각을 하고, Django를 더 깊게 배우기 위해 위에서 추천했던 에듀캐스트의 리액트와 함께 장고 시작하기를 결제하고 강의를 들었습니다.

근데 이 강의를 들으면서 진짜 장고를 배운 것 같다는 느낌이 들었던 건 github에 있는 장고 코드를 같이 보면서 내부에서 어떻게 돌아가는지 프로세스를 가르쳐 주셨기 때문이라고 생각합니다. 근데 이 강의를 듣기 전에 위의 파이썬 알고리즘 인터뷰 같은 책을 통해 파이썬의 문법, 자료구조, standard library의 사용법을 배우고 듣는 것이 좋습니다. 그래야 강의를 100% 이해할 수 있기 때문입니다.

최근에 유난히 코딩을 가르치는 곳들이 많아지고, 가르치는 방식도 다양하다 보니 어느 걸 들어야하는지 고민하시는 분들도 많을 것 같습니다. 컴퓨터 공학 기초를 탄탄히 하고, 응용을 배우는 게 좋다고 생각하지만 저부터 딱딱한 이론 강의를 좋아하지 않다보니 이렇게 마구잡이로 공부했던 것 같습니다. 그래서 다른 분들이 어느정도는 이런 순서로 공부하면 좋지 않을까라는 생각을 하면서 글을 써보았습니다 :)

Function Based View를 사용하고 싶으면 @api_view

Class Based View 사용하고 싶으면 APIView, Generics.~~APIView, Viewset 중 하나

APIView는 View(Rest Framework에 있는게 아닌 Django에 있는 것)를 상속받긴 하지만 거의 백지상태. 안에 만들고 싶은 Http method를 골라서 만들어주면 됨. (ex. get, post, put, delete ...)

Generics.~~APIView와 APIView 사이에 GenericAPIView가 있긴 한데 둘을 이어주는 징검다리 느낌. GenericAPIView를 써본 적은 없음. 이제 ListAPIView, ListCreateAPIView, DestroyAPIView 등등이 있는데 단어 하나가 붙을 때마다 그 Mixin같이 따라 온 거라 보면 됨. (ex. ListAPIView는 APIView에 ListModelMixin이 같이 와서 List Method를 이미 어느정도 만들어 놓음)

Generics에 있는 View들은 get, post, put, delete method를 잘 가공해서 List( or Retrieve), Create, Update, Destory로 만들어 놓음. 그래서 get, post method를 보면 그냥 가공해 놓음 List( or Retrieve), Create method를 부르기만 함.

Viewset과 APIView 사이에도 GenreicViewset이 있긴 한데 이것또한 징검다리 같은 느낌. Viewset들은 위의 Mixin들은 많이 넣어서 더 편리하게 만들어 놓음. ModelViewSet은 Mixin들을 모두 넣어 놓았고, ReadOnlyModelViewSet은 get만 가지도록 List와 Retrieve Mixin만 가져옴.

참고 문헌: http://www.cdrf.co/