npm ‘kik’사건을 얘기하는 페북의 글과 코멘트를 보고..

블로터의 “11줄의 코드, 인터넷을 패닉에 빠뜨리다(http://www.bloter.net/archives/253447)”

Screen Shot 2016-04-04 at 2.45.50 PM

kik 홈페이지 캡쳐

흠.. 오늘의 뜨거운 감자는 요 녀석인거 같은데..
본문 글도 코드 라인을 강조하고 있고, 페북에서 공유된 글 및 글의 코멘트에도 코드 라인에 대해서 비아냥거리는 사람이 있던데..
이들 중에 실제로 한 줄짜리, 두 줄짜리 패키지 코드를 봤다고 말하는 사람은 없었다. 그리고 실제로 찾아서 본 사람도 없을 것이다.

모두의 예상처럼 거지 같은 패키지일 수 도 있다.
근데.. 단순히 코드 라인 수로 코드의 퀄리티를 얘기한 건.. 어거지 아닌가?
자 그럼 구구단 코드를 1,000줄로 짠 거랑, 1줄로 짠 거랑 비교하면..
1,000 줄인 코드가 훨씬 훌륭한 것인가?

코드 라인수는 중요하지 않다.
해당 코드가 나오기까지의 많은 고민과 경험이 중요한 것이다.

 


 

바퀴 만드냐 사용하냐 하며 싸우는 분들 보고..
실소가 나온다. 너무나 오래 묵혀서 묵은내만 나는 소재거리를 가지고 얘기하다니 ㅋㅋ
내 생각은 아래와 같다.
그냥 상황에 맞게 쓰면 된다.
오픈소스 중에 개발하려고 하는 것과 동일한 패키지가 있고 라이센스가 문제없으면 사용하고
수정할 부분이 있으면 수정해서 사용하고
맘에 안 들거나 기능상 문제가 있으면 다른 걸 찾거나 만들면 그만이다.
“있는 바퀴를 쓰거나”, “바퀴를 만들거나” 이렇게 두 가지의 선택지만 있는 게 아니란 거다.
중요한 것은 기획한 의도대로 기능이 동작하고, 개발하기 편하며, 유지 보수도 좋은 걸 선택하는 거다.
그게 있는 바퀴를 사용하는 걸 수 도 있고, 새로운 바퀴를 만드는 걸 수 도 있다는것이다.

zenhub.io를 2주간 써보고

Screen Shot 2016-02-25 at 6.20.54 PM

zenhub를 간략하게 소개하자면 브라우저 확장 기능을 이용해서 Github를 방법(?)하여 칸반보드(Kanban Board)와 번다운(Burn-down)챠트를 제공하는 유료서비스다.
하지만 트라이얼 기간 2주를 제공하기 때문에 zenhub의 기능은 충분히 맛볼 수 있다.

feature-boardburndown-chart

zenhub를 2주간 써보고 그간 느낀 점을 간략하게 장점과 단점으로 나누어 정리하려 한다.

장점

  • 별도의 이전(Migration) 작업 없이 기존의 이슈들이 그대로 칸반보드에 적용된다.
  • 검색 필터들이 복수 선택이 가능해진다.Screen Shot 2016-02-25 at 6.24.50 PM.png
  • 스코어링이 가능하며 기본값으로 피보나치수열이 들어가 있다.
  • 번다운차트가 제공된다.

크게 이 정도 것 같다.
물론 다른 장점도 더 있을 수 있겠지만 그건 zenhub라서 라기보다, 칸반보드의 장점인 경우가 대다수이다.

단점

  • 익스텐션의 한계로 초기 로딩이 좀 느리다.
  • 마찬가지로 종종 먹통이 되거나
  • 레이아웃이 깨질 때가 있다.
    Screen Shot 2016-02-15 at 6.25.20 PM
  • 칸반보드에서 이슈의 코멘트 개수를 확인할 수 없다.
  • 같은 맥락인데 이슈의 activity가 있는지를 알아낼 수 없다.
    Screen Shot 2016-03-02 at 11.22.41 AM
    코멘트가 몇 개나 달렸는지, 내가 놓친 Activity가 있는지를 확인할 길이 없다.
  • 이슈들을 통으로 다른 pipeline으로 옮기는 기능이 없다. (예를 들어 Backlog에 있는 모든 이슈를 Todo로 옮기려고 하면 이슈 하나하나 클릭해서 옮겨야 함. 전체 선택 이딴 거 없음)

결론

  • 디테일한 부분에서 완성도가 떨어진다.
  • github에서 칸반과 번다운만 제공할뿐이다.(번다운은 대체품도 몇몇 있다)
  • 돈 내고 쓰기엔 아직 부족하다.
  • 심지어 가격이 저렴한 편 도 아니다.
  • 더 저렴한 가격으로 이용할 수 있는 서비스도 더러 있다.
  • 칸반을 별도의 설치 및 추가 비용 없이 체험해본다는 차원이면 추천.

서버를 Rails5로 할것이냐, Meteor(nodejs)로 할것이냐

뒤늦게 Rails 5Action Cable Demo 동영상을 보았다.
동영상은 20분이 조금 넘는 런닝타임이지만 익숙해지면 3분 내외로 개발할 수 있을것 같다.
그런데 생각보다 많이 풀어져있는(풀이되어있는) 느낌으로 각 사이드별로 코드를 다 작성해야한다.
“웹소켓을 하기 위해서, 여기는 이렇게, 거기는 그렇게, 저기는 이렇게, 마지막으로 이렇게 해주면 끝. 짜잔~!! 참 쉽지?”

3591057515594fc8

공들고 뛰어가다 그냥 점프해서 골대에 공 넣으면돼

처음 시도하는 사람들에겐 개념이 명확해서 이해하기 쉬울수있겠지만..
아직까지는 복잡하다는게 내 생각이다.

그리고 사실 Rails는 쓸대없는 코드 작성을 최소화하여 빠르고 간결하게 개발하는것이 장점이자 철학이라고 생각하는데 Action Cable은 그렇지 못한 느낌이다.
뭐 아직 베타니깐 버전업이 되면 아마 조금씩 이 철학에 맞춰서 수정되지 않을까 싶다.

내가 만약 Meteor​를 해보지 않았다면 이런 생각을 안했을수도 있겠지만
Meteor는 “그냥 했을뿐인데 웹소켓통신이 되고있네?” 랄까..

restmb_idxmake

그냥했는데 펜타킬..

Meteor랑 비교하는것 자체가 어폐가 있을지모르겠지만, 그래도 이미 맛봐서 비교를 안할수가없다.

사실 Rails를 버리고 Meteor + React​ 조합으로 서비스를 꾸려나갈 생각이었는데..
Rails 5선택지가 생겨서 고민이된다.

1-kyrdrgja-esr1w8taqong

아직 당장은 웹소켓을 쓸일이 없다보니 이 옵션은 선택에 큰 영향을 끼치진 않을것같다.
다만 Rails 5의 API mode가 어떻냐에 따라 갈라지지 않을까싶다.

API mode가 내가 원하는(상상하는)모습이라면
Rails 5 API mode + React로 구성을 해도 괜찮지 않을까?

Rails, Meteor 둘중 무엇이 더 가벼운가? 무엇이 개발하기 빠른가? 등등의 이슈로 열거해놓고 선택할 수 있겠지만..
사실 Ruby할래? Javascript할래? 의 문제이지 않을까 싶다.
무엇이 더 재밌고 즐겁게 개발을 할 수 있을것인가?
선택하기 어렵다. Ruby도 Javascript도..

Ruby는 10년이 넘는 기간동안 오랜시간을 함께한 친구같고..
Javascript는 Ruby보다 훨씬 오래전부터 알았지만 서먹한 관계였다 최근 몇년동안 급 친해진 친구랄까..

1431853362247

어떤거쓰지?

 

참고링크:
http://rubyonrails.org
http://weblog.rubyonrails.org/2015/12/18/Rails-5-0-beta1/
https://github.com/rails/rails/tree/master/actioncable
https://www.meteor.com/
https://facebook.github.io/react/

 

Meteor Up 삽질기

Meteor Deployment 검색해보면 모든 예제가 전부 Ubuntu였음.
개인적으로 서버는 항상 Debian을 선호해서 찜찜하지만 ‘Debian이나 Ubuntu나~’하면서 Debian 강행.
배포 안됨.

Debian이라서 문제인건지.
apt로 mongodb를 설치해서 문제인건지
nvm으로 node를 잡아놔서 문제인건지..
mup 계속 실패. deb-mup(데비안용 mup)또한 마찬가지.
설정 바꾸며 삽질해도 안됨.
5초 설정 바꾸고 배포 결과 떨어지는데 5분~10분..
결국 모든 설정과 의심되는 부분 다 작업해도 안됨.
이것때문에 반나절 날림.
큰맘먹고 Ubuntu로 바꿈.
정말 한.번.에됨.

결론.
Meteor Server는 Ubuntu를 쓰자 -ㅅ-;

Textmate2 CoffeeScript 공식 Bundle 업데이트

Textmate2에서 CoffeeScript 공식 번들을 사용했을때
단어선택을 하면 뒤에 있는 공백까지 선택되는 이슈가 있었다.
좀 더 정확하게 말하면 단어와 =(이퀄)사이에 공백이 있을 경우 선택된거지.
정규식으로 풀면 \w+\s?(?=\=) 요렇게?
tm-coffee

암튼 번들을 직접 고쳐서 사용할려고 했는데 아무래도 공식적으로 수정되는게 나을것 같기도 하고
번들의 어느부분을 고쳐야할지 감을 못잡아서 그냥 Textmate에 메일을 보냈는데
바로 다음날 수정하고 공식 번들이 업그레이드 되었다 +_+

고로 Textmate2에서 CoffeScript 공식 번들 쓰시는분은 업데이트되었는지 체크 한번해보시길! ㅎㅎ

Yosemite의 Terminal에서 HOME, END키 사용하기.

Yosemite의 Terminal에는 기본적으로 HOME, END키가 bind가 안되어있네요.
(기존에 설정되어 있으셨던 분들은 큰 문제 없을것 같은데.. 확인은 못했습니다.)

예전처럼 Terminal의 Preferences로 들어가신 후 Profiles탭을 선택.
그리고 Keyboard로 들어가신 후 + 버튼을 눌러서 새로운 키 바인드를 추가합니다.

Terminal -> Preferences -> Profiles -> Keyboard

Terminal Preferences에서 Profiles를 선택 그리고 Keyboard 선택하면 바인드된 키 목록을 볼 수 있음. 여기서 추가/삭제 수정이 가능

그리고 난 후
HOME키 설정.
Key: Home,
Modifier: None,
Action: Send Text
Value: 33[H
를 입력해주세요. 워드프레스가 Value를 이스케이프해버려서 제대로 안나오네요.
아래 첨부한 이미지의 글자를 넣으시면 됩니다.

Screen Shot 2014-10-20 at 1.43.11 PM

END키 설정
Key: End,
Modifier: None,
Action: Send Text
Value: 33[F

Screen Shot 2014-10-20 at 1.43.16 PM

끝.

Screen Shot 2014-10-20 at 1.51.14 PM

Elasticsearch dynamic scripting

Elasticsearch 1.2.x 미만 버전에서는 dynamic scripting이 기본으로 활성화(able)되어있다.
이건 보안 이슈를 가지고 있는데 자세한 정보는 아래 첨부해드린 링크를 참고하시면 되고
http://bouk.co/blog/elasticsearch-rce/
http://www.elasticsearch.org/community/security/
http://www.elasticsearch.org/blog/scripting-security/

해결책은 간단하다. elasticsearch.yml에서

script.disable_dynamic: true

를 추가해주고 재시작하면 된다.