서버를 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

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

신입들에게 당부 – 질문시 유의사항

신입들이 작업을 하다보면 사수나 상사에게 질문을 하게된다.
근데 여기서 주의할점은 쉽게 질문을 하면 안 된다는 것이다.

1. 사수의 시간은 소중하다고!!

우선 알아야 할 것은 사수도 작업중이다는 사실이다.
내 질문으로 인해 사수의 몰입이 깨지게 될 수 있다는걸 항상 유의해라.
입장을 바꿔놓고 생각해보라.
내가 한참 열심히 몰입해서 코딩하고 있는데 누군가 와서 훼방을 놓는다면 어떻겠는가?
고로 아무때나 질문하지 말고, 적당이 눈치를 보며 질문할 타이밍에 질문을 하라.
여기에 감사한 마음도 함께 표한다면 더 좋을 것이다.

2. 검색하면 1초만에 답이 나올 질문은 하지 마라.

신입이던 디자이너건 기획자건, 모르는게 있으면 그냥 다 개발자한테 질문을 한다 ㅋ
검색하면 1초만에 답이 나오는걸 그냥 막 질문한다.
이건 문제를 해결하려는 최소한의 노력도 안 했다는 의미이다.
난 이런 사람들 도저히 이해를 할 수가 없다. 솔직히 이런 질문 받으면 짜증난다.
이 짜증으로 인해 나의 몰입은 당연히 깨지게 된다. 다시 몰입하기까지 걸리는 비용과 노력을 보상받을수 있는것도 아니다.

3. 리소스 차이

무엇보다 신입과 경력직의 리소스는 차원이 다르다.
신입이 밤새면서 낑낑거려도 못하는걸, 경력직은 10분만에 해결하는 경우가 비일비재하다.
신입의 질문으로 인해 사수는 업무에 방해를 받는것뿐만 아니라, 본인 업무에 사용해야할 리소스를 신입에게 사용할 수밖에 없다.
근데 질문이 허무맹랑하거나 검색하면 바로 나오는 것이면 얼마나 빡치겠는가?
자신의 몰입은 이미 깨졌는데 말이다.

4. 선생님!

회사는 학교도 학원도 아니다.
고로 사수는 선생이 아니라는 뜻이다.
가만이 앉아있으면 사수가 알아서 가르켜줄거라 생각치도, 바라지도 마라.
냉정히 말하면 사수는 신입의 질문에 답변을 해야할 의무 또한 없다.
(사수는 부사수가 성장하든 안 하든 무관심해도 된다는 의미가 아니다.)
어미새가 새끼한테 모이주는 모습을 기대하지 마라.
공격적인 자세로 공부하고 시도하고 삽질하고 질문하라.

5. 쉽게 얻으려 하지 마라.

사수에게 질문을 하면 쉽게 답을 얻을 수가 있다.
하지만 이것이 습관이 되지 않도록 주의해라.
쉽게 얻은 건 쉽게 잊어먹는다.
스스로 노력하는 것이 중요하다.

6. 좋지 않은 질문수만큼 나쁜 평가(평판)을 받는다.

질문의 퀄리티에 따라 달라지겠지만. 보편적으로 신입이 하는 질문의 퀄리티는 거기서 거기다.
이러한 질문의 수가 많다는것은
스스로 문제를 해결하려 노력하지 않았다는 걸 뜻하며,
사수를 배려하지 않고,
그저 지식인으로만 이용했다는 뜻이다.
이러한 인재는 성장하지 않는다
아울러, 사수 시간 빼앗아서 일 못하게 하고, 멘탈 뽀개서 일 못하게 하는데
그 어떤 사수가 좋은 평가를 내리겠는가?

7. 질문은 최후에

질문하기 전에 거쳐야 할 프로세스를 알려주겠다.
이 프로세스는 개인적으로 만든 방침이라 사람에 따라 다를 수 있다는걸 참고해주길 바라며. (개인적으로 30분 법칙이라 부르고 있다.)
작업을하다가 막혔을때 바로 질문 하기보다는

  1. 차분한 마음으로 침착하게 로그를 분석해라. 99.999999999%의 경우 로그에 힌트가 있다.
  2. 힌트에 근거하여 코드를 보고 원인 파악 및 수정을 해라.
  3. 해결이 안된다면 검색을 해라.
  4. 검색 결과에서 힌트를 얻어 수정해보고, 안되면 다시 검색, 수정, 검색, 수정..
  5. 30분이 지났는데 해결이 안되었나? 그럼 그때 질문을 해라 그리고 이때까지 한 삽질을 보고해라

30분으로 정한 이유는 간단하다.
30분이 지나도 해결 못하는 문제는 1시간이 지나도 해결 못하는 문제일 확률이 높기 때문이다.

사수를 봉으로 여기지 말고 존경하도록 노력해라.
부사수가 날 봉으로 보는지, 존경하는지 사수는 다 알고있다.

하드탭 예찬론

1. 탭 사이즈가 너무 넓어요? 하드탭 구려요?

내가 인터뷰 심사관이라면 이런 질문하는 개발자 절대 안뽑는다.
개발 툴에서 탭간격 수정할 수 있다.
본인 입맛에 맞게 수정해서 쓰면 되는 일이다.
그리고 엄밀히 말해 탭 사이즈는 하트탭에 대한 불만이 아니다.

2. 소프트탭은 내가 사용하는 탭사이즈와 상관없이 인덴트가 고정됨

나는 인덴트 2Spaces가 좋다. 근데 4Spaces이면 살짝 짜증이 난다. 그리고 눈에 익숙치 않아서 가독성 자체도 떨어지게 된다.
그래서  공백 4칸을 2칸으로 수정하거나, 탭으로 수정하는건 엄청난 재앙을 초래한다.
그 이유는
1. diff하면 모든 라인이 다 빨간색, 녹색떠서 깜짝 놀라게 될것이다. 한마디로 diff한 후 수정된 내용을 확인하기가 어렵다는 뜻.
2. 더 심각한건 만약 하드탭(혹은 소프트탭 2Spaces)로 수정했다 하더라도, 다른 사람이 다시 4Spaces으로 수정해서 푸쉬하게 될거라는 사실.
이러한 과정은 무한반복이고, 서로 감정만 상하게 될 뿐이다.
앞서 말했지만 탭으로 코딩하면 소스 코드 변경없이 에디터에서 Spaces를 변경 가능하므로 스트레스 받지 않고 내게 익숙한 환경에서 코딩을 할 수 있는것이다.

3. 협업시 다른 사람 탭사이즈 신경 안쓰고 코딩이 가능

다른 사람이 탭사이즈를 2를 쓰든 4를 쓰든 변태라서 8을 쓰든 상관없다.
그냥 에디터에서 본인이 선호하는 사이즈로 지정하면 끝~!

a = { name: "ASSA", id: "a-1" }
b = { name: "B"   , id: "b-1" }

이런식으로 코딩을 한다고 한다면.. 저기선 탭을 쓰면 안되고 스페이스를 사용해야 한다.
그럼 코드 보여지는 것도 별 문제 없다.
하지만 이런식으로 코딩하는건 좋지 못한 습관이다.

var a = "에이",
    c = "씨";

이런식으로 코딩하는 경우도 있다. 이 경우 하드탭은 문제가 된다.
하드탭을 하면 c가 이상한 인덴트를 가진걸로 보이기 때문에 이럴땐 소프트탭이 확실히 유리하다.
하지만 개인적으로 이러한 컨벤션 또한 선호하지 않는다.

var a = "에이", c = "씨";

이렇게 할 수도 있고

var a = "에이";
var c = "씨";

이 컨벤션을 더 선호한다.
중요한건 코딩 컨벤션에 스페이스로 코드 레이아웃을 짜지 않도록 약속하면 이 문제는 해결이 된다.

4. 소스코드용량이 늘어난다.

탭과 스페이스 모두 1byte다.
만약 소프트탭 4spaces로 사용하면 4bytes를 사용하게 되는 것이다.
하지만 탭을 사용하면 1byte면 끝난다.
컴파일이 된다면, 사실 코드 용량은 무시할 수도 있다. 하지만 웹에선 조금 다르다.
2002년? 3년즘에 테스트를 해봤던 거라, 10년전 이야기라 지금은 어떨지 모르겠지만
하드탭이랑 소프트탭 4spaces로 IE 7, FF(당시 최신 버전)에서 테스트했었다. (그땐 크롬은 있지도 않았다)
정확한 숫자가 기억나지는 않지만 30배정도 차이가 났다는건 기억이 난다.
IE, FF 두 브라우져 모드 소프트탭이 현저히 느렸다는것도 기억한다.
뭐 지금은 워낙 렌더링 기술이 좋아져서 상관없을것 같기도 하다.
내가 확인하자니 귀찮고, 누군가 해주면 참 고마울 텐데 말이지 ㅋㅋ

5. 인덴트 체크가 힘들어.

하드탭의 경우 보편적으로 에디터에서 가시적으로 확인을 할 수 있다.
하지만 스페이스는 지원을 안 하는 경우가 더러있다.
이렇게 되면 손으로 커서 한칸 한칸 움직이면서 인덴트가 제대로 되었는지 확인해야 한다.
물런 이렇게 인덴트를 확인해야 하는 불상사가 안생기는게 바람직하다.
텍스트메이트에서 노출되는 tab

6. vi에서 수정

개발을 하다보면 서버에 직접 접속해서 코드를 수정해야될때가 가끔 있다.
뭐 vi를 잘 쓰는 사람이라면 바로 첫 번째 스트링으로 캐릭터를 이동시키겠지(^)
그런데 그 방법을 모르는 사람은 커서로 이동을 할것이다.
자. if안에 for있고 막 그래서 인덴트가 4개정도 들어갔다고 해보자.
소프트탭으로 4spaces일경우 4 * 4 = 16번 키보드 커서를 눌러야한다.
근데 탭으로 하면 4번만 움직이면 된다.
사실 이건 vi숙련도에 따라 달라지는 얘기이긴 하지만..

근데..
왜 상당수의 오픈소스들은 소프트탭일까?
내가 Ruby쪽 진영쪽만 자주 봐서 그런가?
무엇이 소프트탭의 매력일까?