2015 PYCON KOREA 컨퍼런스 노트

http://www.pycon.kr/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
      1. 인코딩 파악하기
      • 문서보고, 확인하고 테스트.
      • 주어야하는 인코딩도 명확히

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

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

  • 어떻게 하면 구조가 없는 데이터인 텍스트의 의미를 컴퓨터가 잘 이해할 수 있을까?
  • 단어를 표현하는 가장 쉬운 방법: 이진 표현법
    • 어떤 단어를 벡터화 시킬 수 있다.
    • 근데 이진 표현법 사용 => 단어간 유사도 정의 불가
      • 호텔&모텔 / 호텔&고양이 얼마나 비슷한지 전혀 모름
  • BOW(bag of words)
    • 단어가 문서에 존재한다/안한다(term existance)
    • 단어가 문서에 n번 존재한다(term frequency)
    • 근데 공간의 차원이 너무 커서 문서간 유사도 지표의 효과 떨어짐
  • 워드넷 같은 텍소노미
    • 모든 용어를 포함하려 하지만, 전문 도메인 용어들은 많이 빠짐
  • 단어의 주변을 보면 그 단어를 안다
    • == 단어의 의미는 해당 단어의 문맥(context)이 담고 있다.
    • co-occurence: 두 단어가 정해진 구간 내에서 동시에 등장
        1. Term-document matrix : 한 문서에 같이 등장하면 비슷한 단어
        1. 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
    • 다만 첫번째 고객의 취향에 완전히 맞춤!!
  • 백오피스를 가볍게 두고 고객의 니즈에 더 노력을 쏟음
    • 더 팔릴만한 것 만들기!
    • 이유: 스포카에서의 경험
    • 장점: 장기적으로 효율 좋음. 단, 성공했을 때!!
    • 분석은 엑셀로 <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 (매생이)

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

OKKY Javascript Fullstack Conference 강연노트

11079373_737723709673898_904060683853328553_n

김태곤

  • 서버와 클라이언트에서 동시에 사용하는 ReactJS
  • 김태곤
    • Fancy, Naver, 책번역, 한국어번역
    • taegon.kim, @taggon
  • ReactJS?
    • FB에서 개발
    • 정식 명칭은 React
    • 사용자 인터페이스를 만드는 자바스크립트 라이브러리
  • MVC
    • 여기서 컴포넌트를 통해 오직 View표현만 담당
    • 컴포넌트:
      • 재사용 가능한 UI구성단위
      • html5오면서 표준 됨
      • 컴포넌트는 어떤 기준으로 나눠야 하나? ->본인이 알아서 판단
  • JSX
    • Javascript XML
    • JS코드에 xml을 직접 표현 -> (JSXTransformer를 통해->JS코드로 컴파일
  • DOM
    • 일관성이 없다 – 브라우저마다 구현에 차이가 있다-렌더링 버그
    • 테스트하기 쉽지 않다 – JS만으로는 테스트가 어려워 반드시 브라우저가 필요
  • Virtual DOM
    • 일관성이 있다-브라우저에 의존적이지 않다
    • 테스트하기 쉽다 -순수 JS만으로 구현
    • 빠르다-메모리상에 DOM구성, DOM비교를 통해 업데이트된 부분만 갱신
      • 빠른걸로 성능향상시켜보까!!
      • Ember나 Angular보다 빠르다
    • 단방향 데이터 흐름
    • 이해하기 쉽다
  • 동형 자바스크립트(Isomorphic Javascript)(중요!)
    • 동형 = 같은 모양
    • 클라이언트와 서버가 같은 코드를 공유한다.
    • php-node.js렌더링 서버 구조
  • 이점
    • 반복 작업 제거
    • 서버사이드에서 렌더링 해야할때 반복 제거
    • 사용자 경험 향상
    • 검색 엔진 최적화(데이터가 포함되서 나오니까!)
  • React는 그 이상이댜!!!
    • React Native
      • React를 사용해 네이티브 모바일 앱 작성: eg)Facebook Groups
      • 모바일OS의 네이티브 UI를 JS로 조작
      • 별도 쓰레드에서 동작하는 JS와 비동기 통신
      • 컴포넌트 종류는 다르지만 쓰던 React 방식 그대로
      • 오 쩐다 디버깅을 크롬으로 해
    • React Canvas
      • 모든 돔 엘리먼트를 캔버스에 그려!
    • 리액트의 철학: Learn Once, Write Anywhere!
    • awsome ㅇㅇ라 치면 그 ㅇㅇ의 쩌는것들이 나온다!!(ex. awesome react)

고재도

  • PolymerJS
  • Web Compenet
    • 더 작은 코드, 덜 혼란스럽게!
    • Custom Elements(컴포넌트가 인터페이스를 가진 DOM Element 형태로 사용될 수 있도록)
    • Templates(z컴포넌트의 골격이 사용전까지 비활성화된 상태로 관리되도록)
    • Shadow Dom
    • HTML Imports
    • webcomponents.org 참고
  • 폴리머와 웹 컴포넌트 사용하기
    • 폴리머?
      • 라이브러리
      • 웹 컴포넌트 기반 어플리케이션을 쉽고, 빠르게 만들게 해준다.(jQuery가 javascript 쉽게 만들어준것처럼)
      • polymer.js : 더 편리하게 웹컴포넌트개발을 할 수 있게 해준다.
      • 정의한 엘리먼트들을 “이런식으로 쓸 수 있다.
      • template이란 태그 생김! =>나중에 렌더링
      • 앵귤러랑 비슷하넹… ng-repeat == repeat
  • Shadow DOM
    • light DOM 밑에 숨겨져있다
    • 브라우저에선 보이는데 소스상엔 안보
    • lightDOM : DOM조작 쉽게 가능
    • shadowDOM: 개발자만 알고있다아 접근하기 어려움(capsulation 된다!)(바깥이랑 차단되어있는 상황!)(의도적으로 찾아갈수는 있지만 실수로 부실수는 없다)
    • 폴리머는 기본적으로 shadow dom 적용!
  • core-elemens
    • 오오 시연해주시는데 싱기방기!

문추근(fallroot)

  • DRY – Don’t Repeat Yourself 이 철학을 가지고 임하
  • Grunt, Gulp
    • 프론트엔드 개발도구 using 노드 (자동화에 도움)
  • 앱엔진 + 자바
    • 실제 서비스 환경에서 작업하는 방법이 이상적
    • 수정-> 빌드-> 배포 과정이 번거로움
    • 실제 서비스 데이터를 사용할 수 없음
    • 데이터 CRUD가 불편
  • index.html
    • 간단
    • 단일 페이지에 작업
    • 문제: CORS <-Cross origin resource sharing
      • 원격 자원 접근 제한
      • 해결: JSONP <
      • 코드 분리/재활용 어려움
      • 복붙복붙
      • 수정시 같은작업 반복
      • 데이터베이스 사용 불가능
  • 정적 사이트 생성기
    • staticsitegenerator.net
    • 레이아웃 지원 -> HTML 분리/재활용
    • 마크다운 등 블로그 포스팅에 특화
  • 그래서 루비온레일즈 써봐라
    • 설치가 간단
    • 루비는 스크립트언어 -> 빌드/배포과정 필요없음
    • 기본 기능만으로도 유용
    • 추가 잼 설치로 기능 확장
  • 프리프로세서: 원래 언어의 부족한 문법 보완
  • Sprockets
    • Rack based asset packaging
    • 스타일시트/자바스크립트 파일관리
    • 다 주석으로 생김
  • 스캐폴드
    • 건축에 사용하는 임시 구조물
    • 작업시 편의 제공
  • 초기 데이터 구축
    • 시드: 루비 코드로 초기데이터 작성
  • Pow
    • 랙 기반 서버 관리
    • 웹 서버 포트 충돌 방지
    • Anvil: pow에 UI입힘
  • xip.io
  • 유용한 젬
    • RailsCsvFixtures
    • YamlDB
  • 실제 개발 절차

정병태

  • ebrain Lab
  • Service Worker를 이용한 Offline Web Application 구현
  • Service Worker
    • offline상태에서, 웹 어플리케이션의 준비 단계를 가로채는 방법을 제공하고, 지속적인 background 처리를 지원
  • 할수 있는(있을) 것들
    • Offline Cache
    • Task scheduler
    • Background Sync
    • Push notification
    • Geofencing
  • 근데 IE에서 안돼요 ^^ㅎㅎ…
    • 크롬이랑 오페라만 됨 아직까진