일일커밋(Daily Commit) – 1년 회고

스크린샷 2016-07-02 오후 5.27.21

일일커밋(Daily Commit) – 100일 회고 글을 적은 후 시간이 흘러, 벌써 1년 회고를 쓰게 되었다. 일년 동안 어떤 변화가 생겼는지 기록해두려 한다.

습관

하루에 한 번씩은 꼭 노트북 앞에 앉아 코딩한다 (회사 일 제외).

일일커밋의 제1원칙이다. 이런 식으로 TIL, 개인 프로젝트, 오픈 소스 등에 매일 코딩을 하였다.

에잇컵스라는 IOT 텀블러가 있는데, 100일 동안 물을 꾸준히 마시면 최대 49,000원까지 환급해준다. 100일간 무언가를 꾸준히 하면 습관이 형성되고, 이를 돕기 위한 프로그램이다. 일일코딩도 이와 비슷하게 습관을 만들어준다.

작년 7월만 해도, 프로그래밍 후 공개된 장소에 올리는 것은 가끔 있을까 말까 한 일이었다. 하지만 1년 동안 습관을 들이니, 나와 비슷한 문제를 겪는 다른 사람들도 쓸 수 있도록 더 정성껏 코딩하게 되고, 이를 정리해서 올리는 것이 자연스러운 일이 되었다.

  사실 150일 후, 커밋 그래프에 처음으로 빈칸이 생긴 날 왠지 모를 희열이 느껴졌었다. 자유를 얻은 기분…? 역시 뭐든 적당히 하는 것이 좋다 🙂

커밋한 저장소

1년간 커밋한 저장소는 다음과 같다.

1. 개인 위키 – TIL(Today I Learned)

스크린샷 2016-07-02 오후 5.29.05

배운 것들을 마크다운 문법으로 정리해 올리는 개인 위키이다. 현재 240여 개의 문서들이 담겨있다.
가장 많이 참고한 문서는 파이썬 스타트킷으로, 개발 환경을 세팅할 때마다 본다(항상 까먹는다).

2. 개인 프로젝트 – 하비코딩

스크린샷 2016-07-02 오후 5.29.49

함께 코딩하기 위해 가볍게 개발자들을 모을 수 있는 밋업을 만드는 사이트이다. 개발자용 간단 온오프믹스라 생각하면 된다.
Python, Django로 만든 첫 개인 프로젝트이고, 회원가입/밋업 개최/댓글/참여/태그/검색 등을 한땀 한땀 개발해서 애착이 크다.
깃허브 Issues서머노트 달기를 적어두었는데, 지인이 그걸 보고 개발하여 Pull Request를 날려주었다. 컨트리뷰션을 받는 경험도 참 감동이라는 것을 알았다 🙂

3. 팀 프로젝트 – 9X년생 개발자 모임 블로그

스크린샷 2016-07-02 오후 5.30.54

요즘 가장 열정을 바치고 있는 ‘9X년생 개발자 모임'(페이스북 링크)의 공식 블로그다. Jykell을 이용해 Github Pages로 배포하는 Static한 사이트이며, 스태프 최현묵님이 첫 삽을 깊게 떠주셔서 편히 작업하고 있다.

4. 오픈 소스 – Angular Datatables


HTML Table을 예쁘게 보여주고 기능을 추가해주는 ‘Datatables’의 Angular.js 확장 라이브러리다. 회사 프로젝트에 사용하며 Material Design으로 스타일을 커스텀하다가, 하는 김에 컨트리뷰션도 했다. 그것에 맞추어 홈페이지 스킨도 변경해서 Pull Request를 보냈다.

사실 Star 750개짜리인 큰 프로젝트라 반려될 각오도 했는데 Merge되어 약간 어안이 벙벙하였다 🙂

많은 사람들이 내 디자인을 쓴다니… 적은 노력으로 날로 먹은 기분이다.

5. 오픈 소스 – JUI

스크린샷 2016-07-02 오후 5.33.15

제니퍼소프트에서 만든 UI 프레임워크다. 문서를 보다 Footer에 오타가 있길래 수정하여 Pull Request를 보냈다. 정말 날로 먹은 풀 리퀘스트. 이것이 내 첫 오픈소스 활동이었다. 작은 코드도 머지될 수 있다는 용기를 준 프로젝트이다.

공유

나 자신의 코딩 습관을 키워준 것 이외에도, 일일커밋은 나를 더 큰 세상으로 이끌어주었다.

1. 책

스크린샷 2016-07-02 오후 5.33.51.png

일일커밋 100일 회고 블로그 글을 보고, 한빛미디어 출판사에서 연락이 왔다. 이 인연으로 '훌륭한 프로그래머 되는 법'이란 책 말미에 작은 챕터로 '일일 커밋'글을 싣게 되었다(책 제목을 말할 때마다 부끄럽다ㅎㅎ).

2. 토크콘서트, 특강

국민대에서 '여성 개발자 토크콘서트' 패널로 신입 개발자의 삶에 대해 이야기 하고, 후에 '신입 개발자 생활백서'란 이름으로 다시 2시간 가량의 특강을 하게 되었다. 여기서도 '일일 커밋'이야기를 유용하게 써먹었다.

3. 패스트캠퍼스 강의

13490855_1183308781720031_6569680340315071918_o

슬라이드 쉐어에 공유한 신입 개발자 생활백서 발표자료를 보고, IT 실무교육 아카데미 패스트캠퍼스에서 강연 요청이 왔다. ‘더 나은 개발자가 되는 실전 팁’, ‘TIL 제작 실습’, ‘팜므어 번역기 제작 실습’으로 7시간동안 비전공자 대상으로 강연하였다.

다음 목표

일일커밋과 함께한 이 1년으로 ‘함께 개발’하는, 소셜 코딩의 첫 시작을 열게 되었다. 이로서 쪼렙인 내가 고수들과 함께 시간과 장소를 넘어 개발할 수 있게 되었다. 웹이란 참 아름다운 기술 🙂

만들고 있는 하비코딩과 9XD 사이트를 잘 다듬어, 많은 사람들과 함께 쓸 수 있도록 배포하는 것이 다음 목표이다.

Advertisements

‘9x년생 개발자 모임’탄생 이야기

3회 포스터-1

서서 들어도 좋으니 참석하고 싶어요

D2의 장소 후원이 결정된 다음 날 오전 11시. 온오프믹스와 페이스북에 ‘제3회 모임 공고’를 올린 지 2시간 만에 60명의 인원이 마감되었습니다. 참여 인원만큼의 대기자가 생기고, 서서 들어도 좋으니 참석하고 싶다-는 메일이 옵니다. 샐러드, 커피, 도서, 기념품 등 물품 후원을 해주신다는 분들이 먼저 찾아오는 이 모임은 어떤 곳일까요.

9X년생+개발자 = ?

IMG_4908
‘9X년생 개발자 모임’. 90년대에 태어난 개발자들이 모이는 그룹 같아 보입니다. 위엄있어 보이진 않네요. 17세~27세 사이의 친목 모임인가요? 과연 이들이 모이는 것엔 어떤 의미가 있을까요.

‘9X년생’이란 제목은, 나이 부심(…)을 부리는 것이 아닌, ‘명분’을 주는 키워드일 뿐입니다. 커뮤니티 활동은 개발자에게 매우 중요합니다. 우물 안 개발자가 되는 것을 벗어날 수 있으며, 새로운 기술의 습득, IT에 대한 공감, 혹은 이직의 기회 등을 얻을 수 있습니다. 무엇보다, 같은 직군 사람들끼리 웃고 떠드는 것은 즐거운 일입니다.

하지만, 시작은 쉽지 않죠. 특히 이제 개발을 시작하는 사람들이나 사회초년생들은

‘아는 게 없는데 내가 가도 되려나’

라는 생각에 모임 나가는 것을 많이들 주저하곤 합니다. 혹은 용기를 내 모임에 갔는데, 기술 스택도 높고 연령대도 차이가 나서 몇 마디 못 꺼내고 오신 분도 있을 것입니다.

하지만 ‘9X년생 개발자 모임’은 그저 90년대에 태어나기만 한 분이라면,

‘나도 9X년생인데, 한 번 가볼까?’

라는 마음을 먹을 수 있는 명분을 줍니다. 이를 초석으로, 앞으로 더 많은 커뮤니티에 참여하도록 하는 것이 우리 모임의 목표입니다. 즉, 굳이 9X년생이 아니더라도 위의 목적에 부합하는 분들은 모두 참석 가능합니다(혹은 얼굴 나이가 9X년생이시라면 명예 참석 인정합니다).

 

가서 무얼 하나요?

지난 1, 2회 모임은 아래와 같은 순서로 진행되었습니다.

0.키노트
DSC04371
9X년생 개발자들이 모인 의의를 간략히 말합니다.

1.30초 자기소개
DSC04356
모든 사람이 돌아가며 30초씩 자기소개를 합니다. 이는 본인을 알리는 일임과 동시에, 모임 초반에 모두 한마디씩 하게 되어 참여감을 높이는 중요한 순서입니다.

2.9X TALK
IMG_4941
자극이 되는 사람은 유명인이 아닌 친하게 지내며 어울릴 수 있는 또래라는 모토 하에, 다섯 명의 연사들이 10분씩 발표합니다. 2회 때는 ‘삼성을 퇴사하고 스타트업에 들어간 이유’, ‘개발자로서 창업을 한 이야기’, ‘지난 2년 간 회사에서 배운 것’ 등의 주제들로 발표해주셨습니다.

3.네트워킹
DSC04423
40분간 자유롭게 돌아다니며 이야기를 나누는 시간입니다. 자기소개에서 ‘게임 개발을 하고 있다’ 라 말한 사람에게 가서 이것저것 물어볼 수 있는 순서입니다.

4.뒷풀이
S__4235274
행사가 모두 끝난 뒤, 더 이야기를 나누고 싶으신 분들과 함께 뒷풀이에 갑니다. 반 이상의 사람이 참여합니다.

어떻게 시작하게 되었나요

DSC04428
사실 처음부터 ‘사회 초년생의 커뮤니티 활동 장려’를 생각하며 만들진 않았습니다. ‘9X년생 디자이너 모임’은 있는데 왜 개발자 모임은 없지?라는 의문에 동기들 5명을 초대해 페이스북 그룹을 만든 것이 시작이었습니다. ‘9X년생’, ‘개발자’라면 왠지 반드시 가입해야 할 것 같은 모임 이름 때문이었는지, 회원은 빠르게 늘기 시작하였고 500명이 되었을 때 신년회를 빙자한 첫 모임을 가졌습니다.

그 첫 오프라인 밋업에서, 이 그룹에 대한 생각이 180도 바뀌었습니다. 기존 모임에선 얻을 수 없었던 ‘또래와의 공감’, 그리고 같은 직군의 같은 나이대 사람이 전하는 ‘진솔한 이야기’는 상상 이상의 자극으로 다가왔습니다. 세 번의 모임동안 빠짐없이 참석하는 정기 멤버 분들도, 집에 오는 길에 “아, 정말 재미있었다” 를 10회 반복해 말한 참석자도 저랑 비슷한 기분을 느꼈을 거란 생각이 듭니다.

앞으로

IMG_4972
다음 모임부터는 운영진과 함께, 제가 생각하지 못했던 새로운 것들을 기획할 예정입니다. 또한 제가 빠지더라도 원활히 굴러갈 수 있는 탄탄한 모임이 되길 지향하고 있습니다. “이제 개발 시작했다고? 9XD 모임 한 번 나가보면 되겠네” 라는 말이 자연스레 나왔으면 좋겠습니다.

또한, 우리 모임은 ‘사회 초년생 개발자 모임’이 아닌, ‘9X년생 개발자 모임’이기 때문에 의도에 맞게 활발히 활동할 수 있는 기간이 한정되어있습니다. 그 길지 않은 기간 동안, 시작하는 개발자들에게 더욱 큰 세상으로 나아가는 발판이 되었으면 합니다.


페이스북 그룹: https://www.facebook.com/groups/1565641083693087
3회 모임 온오프믹스 링크: http://onoffmix.com/event/68393/

SSH Tunneling

SSH란?

  • Secure Shell
  • 네트워크 보안을 위해 만들어진 프로토콜
  • 인증/암호화/무결성/압축

터널링

  • a.k.a Forwarding
  • A에 SSH클라이언트 설치하고, B에도 설치하고, A의 SSH클라이언트를 통해 SSH서버에 접속. 이 연결 통로를 터널이라 한다.
  • 암호화 등을 통해 터널처럼 외부로부터 연결 보호.
  • 이 터널을 다른 애플리케이션이 이용 가능. => 포트 포워딩(Port Forwarding)

사용 예

$ ssh 서버명

Local Port Forwarding

$ ssh -L 포트번호1:호스트명:포트번호2 서버명
  • 포트번호1: SSH 클라이언트가 검사(Listen)하고 있을 포트번호 지정
    • 이 포트번호1로 데이터가 왔을 때 SSH클라가 SSH서버로 데이터를 전송
    • SSH서버는 이 데이터를 다시 포트번호2로 보냄
      *참고: 포트
  • 1024~65535사이의 임의의 숫자
  • 1~1023까지 포트는 예약된 포트로 보통 수퍼유저만 지정 가능

나의 예시

상황: 회사에서 아마존 DB에 접속하는 키가 있고, 그걸 동료에게 받아서 사용
해결: 동료 개발자에게 키를 받아서 ~/.ssh/폴더에 어쩌구-저쩌구.pem이란 이름으로 RSA PRIVATE KEY를 넣었다.

그리고 아래 명령어를 넣었더니

$ ssh-add -K <key filename>

퍼미션 에러가 떴당 ^^; 햄복할수업성

ssh-add -K 어쩌구-저쩌구.pem
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '어쩌구-저쩌구.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

이 글을 참고해 퍼미션을 변경해주니 완료!

$ ssh-add -K 어쩌구-저쩌구.pem

실행을 해본다.

$ ssh -L 포트번호1:호스트명:포트번호2 서버명

refer

http://www.hanbit.co.kr/network/view.html?bi_id=547
http://118k.tistory.com/64

[개발] Underscore VS Dash, 무엇을 써야 하는가

개인별로 선호하는 스타일이 있겠지만, 서로 알아듣기 편하면 더 좋겠죠?

Dash (-)

  • End user에게 더 익숙하다.
  • 그러므로 url같이 노출되는 영역엔 언더스코어보단 dash(/abount-us) 구글 권고
  • CSS class에서도 dash로 많이 쓴다.

Underscore (_)

  • 보통 띄어쓰기의 의미로 쓴다(+도 많이들 그런다. plus+means+space)
  • 파이썬 등 프로그래밍 소스에서 파일명에서 쓴다 (e.g. password_reset_form.html)
    • 프로그래밍 언어에서 dash가 ‘minus’의 의미일 때가 많음

저 둘 덕분에 꾸벅 인사를 할 수 있습니다. (- -)(_ _)

refer

http://stackoverflow.com/questions/119312/urls-dash-vs-underscore
https://support.google.com/webmasters/answer/76329?hl=ko

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 (매생이)

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

맥에서 window 창 리사이즈 편하게 하기 – bettertouchtool & Spectacle

윈도우 리사이즈를 편하게 해주는 앱 2개가 있는데,
마우스(트랙패드)를 많이 쓰는 사람이면 bettertouchtool,
키보드에서 손을 떼지 않는 분들(i.e 개발자느님)이라면 spectacle을 추천드린다.

Bettertouchtool

스크린샷 2015-07-31 오후 8.46.44

스크린샷 2015-07-31 오후 8.47.23

http://www.bettertouchtool.net/

창을 상/좌/우로 드래그하면 미리 설정해둔 세팅대로 창 크기가 변한다.

Spectacle

스크린샷 2015-07-31 오후 8.47.40

http://spectacleapp.com/

멘토이신 @파이님이 오늘 알려주신 앱.

단축키+화살표 로 윈도우를 크기조절&정렬할수 있다.

기본 단축키는 내가 기존에 쓰던거랑 겹쳐서

ctrl + opt + 방향키

로 바꿨다.