Pycon 2015

Sphinx autodoc (타카유키 시미즈카와)

• docstring
  • API DOCS
• sphinx
  • documentation generator
  • python version is ipt
  • import your code docstrings
  • translation into other languages

Character Encoding in Python (강대성)

• Encoding
  • 전달하고자 하는 내용을 부호화
• Character Encoding
  • 저장/통신 하기 위해선 2진수
• Unicode
  • 전세계 문자/기호를 codepoint에 매칭
  • 한글, 타이문자 등등
  • 많이 쓰이는 이모티콘 등도 정의(똥같은거)
  • Unicode != UTF-8
• UTF-8
  • 모든 Unicode codepoint를 다룰 수 있다.
  • Unicode를 Encoding했을 때 NULL 포함 X
  • ASCII Text는 UTF-8 될 수 있음.
  • 일부 바이트 유실되어도 다음시작 byte알 수 있다(복구가능)
  • Web Encoding중 84%가 사용!
• Unicode Sandwich
• python2
  • default: ASCII
• python3
  • default: UTF8
• Python은 파일의 인코딩을 알지 못함
• 일본어 디코딩
  • 주고 받은 인코딩을 정확히 파악!!
• 인코딩 해결법
  • encode, decode이렇게 저렇게 하다 잘 되면 써요 ==> 망하는 지름길
• 인코딩 파악 위한 순서
  • 문서 또는 서로의 약속 확인
  • 전송받은 데이터 열어서 확인
  • 테스트(반드시!!)
• 인코딩 파악에 도움되는 것
  • chardet 2.3.0
  • n퍼센트 확률로 이 인코딩이다 하고 알려줌
• 테스트
  • 전체 프로그램 돌리면 오래 걸릴 수 있으니 부분을 떼어서 검사
• 파일 IO를 위한 팁
  • 파일을 열 때 codecs쓰면 간단해짐
  • python3에선 내장함수에서 가능
• 결론 TIP
  • 1. Unicode Sandwich
    • python에선 항상 Unicode
  • 2. 인코딩 파악하기
    • 문서보고, 확인하고 테스트.
    • 주어야하는 인코딩도 명확히

한국어 & NLTK & Gensim (박은정)

단어/문서를 컴퓨터가 이해할 수 있게 표현하는 방법

• 어떻게 하면 구조가 없는 데이터인 텍스트의 의미를 컴퓨터가 잘 이해할 수 있을까?
• 단어를 표현하는 가장 쉬운 방법: 이진 표현법
  • 어떤 단어를 벡터화 시킬 수 있다.
  • 근데 이진 표현법 사용 => 단어간 유사도 정의 불가
    • 호텔&모텔 / 호텔&고양이 얼마나 비슷한지 전혀 모름

• BOW(bag of words)
  • 단어가 문서에 존재한다/안한다(term existance)
  • 단어가 문서에 n번 존재한다(term frequency)
  • 근데 공간의 차원이 너무 커서 문서간 유사도 지표의 효과 떨어짐

• 워드넷 같은 텍소노미
  • 모든 용어를 포함하려 하지만, 전문 도메인 용어들은 많이 빠짐
• 단어의 주변을 보면 그 단어를 안다
  • == 단어의 의미는 해당 단어의 문맥(context)이 담고 있다.
  • co-occurence: 두 단어가 정해진 구간 내에서 동시에 등장
    • 1. Term-document matrix : 한 문서에 같이 등장하면 비슷한 단어
    • 2. Term-term matrix : 단어가 문맥 내에 같이 등장하면 비슷한 단어
• word2vec
  • 단어에 대한
• doc2vec
  • 문서/문단 벡터를 마치 단어인 양 학습시키자!
  • 차원 축소
• 한국어 영화 리뷰 토이데이터

Python and Test (배권한)

• 테스트 이점
  • 불안감 해소
  • 테스트 통한 점진적 개선 가능
  • 손으로 하는 수고 덜어준다.
• 어떻게 해야하나
  • TDD추천
  • 느리지만(직접 해보니 5배쯤 느림...ㅠㅠ) 많이 배우고 좋은 프로그램을 짤 수 있다
  • 하지만 만능은 아님.
    • 리팩토링을 수반
  • 하지만 TDD로 개발을 진행할 힘을 얻고, 리팩토링으로 구조 개선
    • 좋은 구조는 또 다른 분야라 생각 ㅎㅎ
• 언제 리팩토링 해야하나
  • Three strikes and you refactor
  • 세 번 이상 같은 것을 하면 안댕!!!
  • egoless programming을 해야 한다.
    • 나의 코드는 의미가 없으며(!=실력없음) 목적을 위하여 언제든 지울 수 있음(==나는 계속 성장할 수 있다).
• 다시, 어떻게 해야하나
  • pyramid
    • unit test해야한다
    • 가급적 테스트는 30초 이내에 끝나야 함(그래야 피드백을 빨리 받고 다른 일을 할 수 있음)
    • 그 여러개의 unit test를 합쳐 integration test
  • Functional test
    • 위에서 아래로
• Obey the test goat 라는 사이트
  • 클린코드를 위한 테스트 주도 개발 <<책 봐라
  • 가급적이면 unit test를 많이 짜는 습관
• 테스트 비용
  • 테스트도 결국 알고리즘 처럼 비용의 세계
  • 인간 확인 비용 < 테스트 짜는 비용
    • 이면 굿. 반대면 인간이 확인해도 됨.
  • 테스트 커버리지가 100%일 필요는 없음(70%만 넘으면 될듯.)
• 테스트 하기 쉬운 코드 짜려면?
  • 테스트를 먼저 짠다.
  • 기능을 많이 나눔
  • 코드리뷰를 거친다
  • 의도를 잘 나타내야함
  • 가독성
• CI를 통해서 협업
  • 깔끔한 환경에서 할 수 있다.
  • 테스트를 돌림
  • 형식을 검사
  • import order등을 검사
• more...
  • py.test를 쓰세요. 이게 좋앙.
  • 다른 분들의 코드를 많이 보세요(e.g. 장고쪽에 좋은 테스트 많다)
  • 더 고민해서 TC를 짜자

탐색적으로 큰 데이터 분석하기 (장혜식)

• EHR(Electronic Health Records)
  • 병원 데이터 - 엄청나게 많은 데이터 쌓임
• 탐색적 데이터 분석
  • 재미있는 것을 찾아야 함
    • 코드 추가/수정이 매우 간편
  • 언제 어떤 데이터가 추가될 지 모른다.
  • 코드는 빨리 만들어서 (거의) 한 번만 쓴다.
  • 그렇다고 재사용이 아예 없는 것도 아니다.
    • 프레임워크가 유연하고 성숙해야 함
  • 데이터가 작지는 않다.
• Jupiter Notebook
  • 인생이 주피터를 쓰기 전과 후로 나뉜다(ㅎㅎ)
    • 판다스도! 두개 꼭 써봐요
• Snakemake
  • make의 좋은점 / 안좋은점
  • 파이썬 코드를 거의 그대로 쓸 수 있다.
  • 의존성이 없는 작업은 병렬로 실행됨
  • 이미 있는 새 파일은 무시하고 지나감
  • File-driven Programming
    • 보일러판이 필요 없는 프로그램 내장형 병렬화 이벤트 루프
• 텍스트 파일
  • tsv(탭으로 구분 텍스트), csv(쉼표로 구분 텍스트)
  • 큰 텍스트 파일을 (엄청쉽게) 병렬처리 하려면?
    • 압축을 안 한다?
    • 파일을 쪼갠다?
    • tabix를 쓴다!
      • bgzf
        • 압축을 여러 개로 쪼개서 압축한다.
        • 앞뒤로 돌아다니면서 탐색 가능!!
        • 100% 하위호환
      • 한계점
        • 초기 인덱싱이 병렬화 X. (오래걸림)
        • 반드시 2레벨 인덱스로 정렬되어 있어야 함
        • 레벨 1 인덱스는 병렬 안됨(맞나?)
• Julia
  • 파이썬과 친한 언어 ㅎㅎ

약속 (하재승)

• ㅎㅎㅎ좋으당!
• 프로그래밍은 다 거짓말

도도와 파이썬 (김재석)

• 스포카가 도도포인트를 만들며 있었던 기술적 의사결정 공유
• Do things that don't scale
  • 다만 첫번째 고객의 취향에 완전히 맞춤!!
• 백오피스를 가볍게 두고 고객의 니즈에 더 노력을 쏟음
  • 더 팔릴만한 것 만들기!
  • 이유: 스포카에서의 경험
  • 장점: 장기적으로 효율 좋음. 단, 성공했을 때!!
  • 분석은 엑셀로 << 인턴도 데이터 분석 가능
  • 디플로이는 heroku로(디플로이 시스템을 만들고 유지보수 하는 것도 부담)
    • 다만 버지니아에서 날아오는데 레이턴시 이슈 ->AWS 도쿄로 옮김
• 빠르고, 점진적으로
• 나쁜 선택
  • 매장이 1000개 가까이 늘어나니 서비스에 대한 요구사항 늘어남
  • 기존 서비스가 커져서 추가가 고통스러웠음(넣으면 서버 터짐;😉
  • 종종 '그 때 제대로 해놨면 지금 이고생 안하는데 ㅠㅠ'후회
  • 하지만 그건 이미 그 코드를 계속 만질 수 있는 미래 시점에서의 평가일 뿐
• 파이썬은 스타트업에게 좋은가?
  • Duct tape
  • 스타텁은 단지 '작은'회사가 아님.
  • 스타텁의 가장 중요한 키워드는 '고속성장'
  • 시어머니봇
    • 코드리뷰를 사람끼리 하면 사실 맘이 상할 때가 있다
    • 봇은 잔인하게 엄격함
    • 봇한테 화가 날 순 있어도 미워하진 않더라
    • 오픈소스로 풀었어요~

R이 판치는 세상에 Python데이터 분석가로 사는 법 (하용호)

• 10분만에 듣는 머신러닝
  • 작대기의 자유도에 따라 성능이 결정
  • 회귀
  • XOR Problem
  • Decision Tree
  • Support Vector Machine
  • Random Forest
    • 놀랍게도 성능이 좋음
• 빅데이터
  • 말 오글거려
• GGPLOT2
  • 애증. 안예뻐
• seaborn
  • 그림 그릴 때 좀더 예쁨
• 파이썬 인터렉티브 노트북
  • 내가 했던 과정이 노트북처럼 주르륵 나온다.
  • 이런 방식이 아니고, 결과만 pdf로 주거나 하면 협업시 데이터를 조금만 고치거나 할 때 힘듦.
  • 그게 아니고, 이렇게 만든 과정을 팀 협업할 때 보면 매우 도움.
• mrjob
  • 느리지만 사실 우리가 개발하는 속도가 더 느림
  • 사실 코드를 한번 짜고 한번만 쓸 때가 많다.
• luigi
  • snakemake랑 비슷(근데 이게 더 좋아 by 용호)
• Spark
  • 하둡보다 선호!(by 용호)

django (매생이)

• 스타트업의 마감시간 == 남은 돈