10_30_b.md

루비 코드 리딩

뭔가 좀 자기소개가 길다. 6분지났는데 아직 본론도 안들어감

자기 경력 소개 컨퍼런스 다닌거 등등..

이 세션은 기술적인 이야기는 없을거다

1. 왜 루비 코드를 읽어야 하는가? 루비베스트 프랙티스 다른사람의 코드를 보면 자신의 장점과 약점을 알수 있다 . 스타워즈 (이건 아마도 도제 느낌으로 공부하란 이야기 일듯) 소스코드는 친구다 공헌, 커미터, 재미있으니까 그래서 몆년전부터 읽어보려고 맘음 먹음 근데 난 씨를 못하잖아 -> 그냥 배워. 전부 배울필요는 없고 그냥 읽을 정도 로만 이 프리젠 테이션에서는 1.9.2-p290을 사용함 에디터는 빔 베이스는 대부분은 씨파일이다 하지만 스텐다드 라이브러리는 rb *.c + *.h / *.rb

모든 건 오브젝트니까 오브젝트부터 보죠. 클래스, 뉴 뉴는 얼록과 이니셜라이즈로 이루어져있음 얼록을 바로 콜하면 이니셜라이즈를 스킵할수있음.

어트리뷰트 (attr_*) push vs. << 이둘은 사실 구현이 좀 다르다. << 는 인자를 하나 밖에 못받음

하스켈 문법.

method_missing -> rb_call -> method_missing 복잡하니까 메서드 미싱은 여기까지 보자

같은 메서드가 여러개 있는데 이름만 1,2,3,4로 구분 근데 커맨트가 안달려있음 예를들면 어레이의 new같은거 이건 좀 혼란스럽다

소스코드를 무서워 하지말것 그건 니 친구니까

레퍼런스 루비 소스코드 완전 해설 루비 언더 마이크로 스코프

언젠가는 제다이가 될꺼야 두려워하지마

질문시간 sorah 리드미 읽으면 좀더 자세한 설명이 있다.

11_00_a.md

루비 시큐리티

루비도 레일즈도 당분간 시큐리티 이슈가 많았다. 한 일년동안 담당자들이 힘들었을듯

음? 잠깐 cve가 뭐지? 공통 취약 & 위험(아마도? 나중에 재대로 알아서 채워두자)

발표하는 회사는

• 에플
• 어도브
• 시스코
• 레드햇
• 기타등등

cve.mitre.org nvd.nist.gov

dhh + rails 는 아주 좋진 않지만 배울점이 많다. 레이즈 3이 나온이후 바뀐점은 너무 많은 잼(장점일수도 단점일수도) 많은 잼은 많은 시큐리티 이슈의 기회가 있다는 이야기 예를들면 ..... (대부분 레일즈에 디폴트로 포함되는 앱들 심지어 rdoc도 있음)

업데이트는 매우 고통스럽다.

업데이트는 보험이다. 근데 마이그레이션 코스트가 있다. 근데 그만큼의 가치가 있다. 밤에 잘잘수있고

시큐리티 이슈를 어떻게 보고하기

disclosure 회사들이 싫어함

구글은 올해에 벌써 130k달러를 지급했음 페이스북은 $500이 미니멈이고 맥시멈은 없음 깃허브도 뭔가있긴한데 얼만진 모르겠다 엔진야드 0에서부터 맥시멈은 없음

만약 버그를 발견했다면 어떻게 하니? 두질문을 먼저 할것

1. 내거아닌거에 접근할 권한이 있니?
2. 다른 사악한무리들을 안보게 할려면 개인적인 컨택이 나음

시큐리티 정책을 확인하세요. 뭐 그래도 문제없어보이면 고치라능.

마지막으로 혹시 잼개발자있니? (좀 있음) 모든잼은 일어나길기다리는 시큐리티 이슈가 있다. 니코드가 완벽하지 않은 이상

쉬움 문제가 나기전에 발견 픽스, 리뷰, 릴리즈, 공지

중간 문제가 남 (최대한 빠르게)픽스, 테스트, 릴리즈, 공지

어려움 최대한 빠르게 반응 이스팩테이션 설정 매 24-48시간반응

픽스, 릴리즈, 고마워 할것

가능한 쉽게가자

질문시간

• 업데이트 안한 어플리케이션은 아직 위험한데 그거에대한 너의 대책은 있냐?
  • 니가 할수있으면 해주면 좋을것같다
• 안들림
  • 니가 잼개발자면 근본 원인까지 가서 고쳐줬으면 좋겠다.
• 안들림
  • 빨리고치는거 이외에는 좋은 방법이 없다.

11_30_a.md

ruby on your rails

go west

tokyo -> kyoto -> matz-e 마츠에는 작은 도시지만 많은 루비 코어 커미터가 있고 루비의 메카이다.

도쿄의 서쪽으론 난 안감 아키하바라, 긴자

아사쿠사루비에서 술자리 있음

자기소개

@a_matsuda

오늘 저녁에 깃헙에서 쏘는 술자리가 있음

루비온 레일즈에서 서쪽으로 가는 방법은? (달마 드립일듯)

not 이나 like 를 쓰면 이미 sql문을 조금써야한다.

근데 따지고보면 불가능한게 아닌게 arel은 지원한다. 단지 좋은 에이피아이가 없을뿐

그래서 everywhere를 만듬 (루비2.0의 refinement를 사용한 ar용dsl같음)

나중에 where.not where.not_like where.like등을 추가했지만 where.not 만 살아남음

왜 레일즈의 액션은 파라메터를 받지 않는가? def show(id) @user = User.find(id) end

def show @user = User.find(params[:id]) end

action_args 라는걸 만들어봤지만 dhh에게 거부 당함

active_decoretor

html5_validations

결론

• 최신을 유지 할것
• 너의 문제를 풀려고 노력하고
• 너의 프로 리퀘스트를를 보내라

13_30_a.md

루비의 동시성

죠제!

오늘 할이야기

• 동시성이 필요한 이유
• 문제점
• 다른언어에서의 배울점

50코어는 비쌈!

오늘의 이야기를 합시다 서버에서 한 프로세스를 사용한다고 합시다. 루비에서 쓰레드를 이야기합니다. 어플리케이션은 쓰레드쎄이프해야하죠

문제(problem)

클래스메서드 현재유저를 생각해봅시다. 입력을받고 메일을 보낸다고 하면..

아마도 우리는

1. 현재유저에 어사인
2. 다른일
3. 이유저에게 메일을 보냄 을 생각할거지만..

사실은 쓰레드끼리 서로 간섭함.

현재유저는 mutable state를 공유함 (글로벌)

그러니까 클래스의 속성을 변경하면 안댐!

루비는 다른 구현을 가진 프로그래밍언어이다.

레일즈2는 쓰레드쎄이프하지 않음 왜냐하면 쓰레드세이프는 다른구현에 다른것을 의미하기 떄문(diff things for diff implementation)

@cached[template] = File.read(template) yarv에서만 쓰레드 세이프

그러므로 다른 루비구현에서 동시에 실행하면 오염됨

이걸해결하기위해 60라인의 코드를 추가했는데 난 이걸 별로 좋아하지않아 너무 길잖아

길면 코드 멘네넌스, 퍼포먼드, 개발 행복에 안좋음.

우리는 이걸 해결하기 위한 좀더 좋은 구문이 필요함

그래서 다른언어는 어떻게 처리하는지 보자

자바

루비는 5개인데 자바는 훨씬더 많음--으웩

해쉬를 캐쉬로 사용하는건 루비에서는 매우 일반적인 패턴이지만.. yarv에서 밖에 안전하지 않다. 그래서 {}대신 ConcurrentHash.new 으로 구현을 바꾸면 간단하지만..

난 별로 좋지않다 복수구현에대해 쓰레드 세이프를 생각하지않으면 위험함

제안 1

hash = Hash.new
hash.concurrent_read!
hash.concurrent_write!

인스턴스 변수에 대해서는..

아토미레퍼런스 라는걸 추가하면 다른컴파일러는 괜찮지만 yarv는 이거 필요없잖아

제안 2 tread.rb 에 atomicreference를 추가

go ...

음 좀 건너뛰고 그래서 어떤 문법을 원하는지 보고싶다.

erlang

루비에서는 쓰레드 코스트 어느정도에요?

제안3

쓰레드를 좀더 파워풀하게 만듭시다.

결론은

우리는 동시성에관한 교육이 부족하다

나의 목표는 해결책을 제시하는게 아니라 당신이 해결책을 재시할수있도록 문제의식을 만드는데 있다. 제안을 해준다면 매우 좋을것이다.

14_30_a.md

Concerning Applications

ActiveSupport::Concern

ClassMethods를 자동으로 extend 해주고 included블럭을 자동으로 base의 스코프에서 실행시켜줌

module AAA
  extend ActiveSupport::Concern
  included do
    has_many :yahoos
    ....
  end

  module ClassMethods
    ...
  end

뭐 이런식.

근데 어디쓸꺼냐?

예를 들어

모델 태그달기가능 (질문, 답변) 답변달기가능 (질문, 답변)

컨트롤러 유저(주인?)(질문, 답변)

keep it glue

의존성을 너무 만들지 말것 base 클래스 에 가능한 적은 메서드를 넣을것

https://gist.github.com/moro/5652724 음...

잘 모르겠다. 어쩃든 클래스용 모듈에 리소스라는 이름 붙이는건 좋아보인다 흉내내봐야지

15_00_a

# 팻 모델 리팩토링

프로젝트 시작했을떄는 그린이었는데 점점 똥떵이가 돼잖아

이똥떵이가 돼는걸 예방하는걸 가르쳐 줄껭

액티브레코드 패턴 은 레일즈가 너희에게 재동하는 복잡성을 재어할 유일한 툴임

장점 간결함
단점 디비랑 도매인 로직이 직접적으로 연결됨

그래서 간결한 여러 오브젝트보다 펫오브젝트가되고
나중에 갓오브젝트 가 됨

전통적으로 스키니 컨트롤러, 펫모델

요즘은? 스키니 컨트롤러, 스키니 모델


https://github.com/codeclimate/refactoring-fat-models