VirtualBox – Vagrant Disk IO 성능개선 방법

Leave a reply

  • VirtualBox 에서 제공하는 공유폴더 기능은 심각한 퍼포먼스 저하가 있다. 따라서 다른 방법으로 파일을 공유하는 것이 성능에 훨씬 유리하다.

    • 참고: Vagrant 개발자인 Mitchell Hashimoto 의 VM 내 파일시스템 성능비교 https://mitchellh.com/comparing-filesystem-performance-in-virtual-machines

    • 해결법 – shared folder 를 NFS 로 공유하기 또는 Rsync 로 공유하기 (Rsync는 Vagrant 1.5 이상에서 동작)

      • NFS 로 만드는 방법 간단요약 – 참고: https://coderwall.com/p/uaohzg https://docs.vagrantup.com/v2/synced-folders/nfs.html

        • Host only Adapter 추가 – Virtualbox > VM

        • private_network 행 추가 – Vagrantfile

        • shared_folder 에 type: nfs 추가 – Vagrantfile

      • Host OS 의 /etc/exports (NFS 설정 파일) 에 Vagrant 가 자동으로 행을 추가하기 때문에 vagrant up 도중 sudoer 패스워드 물어봄

    • Rsync 는 일반적인 Rsync 와 동일하게 동작한다. Guest 와 Host 양쪽에 rsync 명령어가 있으면 활용이 가능하다. 윈도우에서도 msysgit, MinGw, Cygwin 에서 Rsync 기능 제공 중

      • 다른 shared folder 타입들과 달리 rsync 명령어를 활용하기 때문에 Rsync 는 vagrant up 때 한번 싱크. 따라서 자동으로 파일 변화를 감지해 싱크를 맞춰주는 vagrant rsync-auto 를 사용해야 함.

하이브리드 프론트엔드 개발 5원칙

Leave a reply

3년 정도 하이브리드 플랫폼들을 경험했다. 하이브리드 플랫폼은 정말 여러 곳에서 쓰이고 있다. 하지만 그 모든 플랫폼이 크롬, 파이어폭스만큼 우수한 디버깅 환경을 제공하지는 않는다. 에뮬레이터를 지원하지 않는 경우는 부지기수이고 한 줄이라도 수정하면 앱을 종료했다 다시 켜야 변경사항이 반영되는 때도 있다.

오늘도 하이브리드 개발 중에 API 서버가 죽었다. 일정도 꼬인 김에 하이브리드 개발 때 도움이 될만한 팁을 공유해본다.

독립된 API 서버를 갖춰라

가능하다면 독립된 API를 갖는 게 좋다. 하이브리드 앱은 API와 통신이 많은 부분을 차지한다. 끊임없이 개발되고 있는 와중에 개발 중인 API가 안정적이기를 바라는 것은 무리다. 하지만 최소한 지금 프론트엔드 개발 중인 API는 안정적이어야 한다. 따라서 독립된 API 서버를 확보해서 현재 개발 중인 부분의 API 는 안정적으로 동작하도록 버전 관리 시스템의 리비전을 변경하면서 개발하자. “가능하다면” 이란 단서를 달았다. 만약 독립된 API 서버가 없다면 원활한 개발을 포기하면 된다.

ps. 단순한 프로젝트라면 API 서버를 대체할만한 목업 서버라도 만들어서 쓰기를 강력히 추천한다.

ps2. Vagrant나 Docker 사용도 추천할만 하다.

프락시를 활용하라

하이브리드 플랫폼에서는 hosts 파일을 변경하기 어렵다. 따라서 다른 방법으로 우회해야 하는데 그것이 바로 프락시다. 단말기의 네트워크 설정에서 프락시 서버를 사용하도록 하고 프락시 서버설정을 변경해 hosts 와 같은 효과를 낼 수 있다. 리버스 프락시와 PAC(Proxy Auto Config) 를 사용한다면 더 편리한 개발이 가능하다. 단말에 탑재된 소스 중 일부만 로컬서버에서 동작하게 할 수도 있고 문제가 있는 API 만 다른 API 서버로 우회하도록 동작시킬 수도 있다. 특히 소스를 곧바로 고칠 수 없는 환경에서 프락시는 활용도가 무척 높다. 가끔 프락시 조차 지원하지 않는 단말기가 있다. 이럴 때는 Wireless AP 를 만들어 해결하는 방법도 있다.

최대한 웹 브라우저에서 확인할 수 있도록 개발하라

하이브리드 애플리케이션은 단말 전용 API를 이용해 브라우저보다 더 많은 기능을 사용할 수 있다. 하지만 전용 API 를 사용한 특별한 부분을 제외하면 거의 모든 기능은 브라우저로도 동작할 수 있다. 어떤 하이브리드 플랫폼도 브라우저만큼 개발환경을 지원해주지 못한다. 따라서 기능 대부분을 브라우저에서 확인할 수 있도록 개발하는 것이 좋다.

가끔은 브라우저용 폴백을 직접 만들어야 할 때도 있다. 예를 들어 화면간에 파라미터를 전달하는 기능은 URL hash에 JSON 을 담아 전송하면 쉽게 파라미터를 전달할 수 있다. 하이브리드 플랫폼에서 데이터베이스를 사용할 수 있다면, Ajax로 데이터베이스에 접근하는 간단한 서버프로그램을 작성해 활용하면 브라우저에서도 쉽게 확인할 수 있다.

플랫폼에서 제공하는 디버깅 도구에 대해 공부하라

브라우저에서 디버깅하는 방법에 대해 잘 알고 있는 만큼 개발중인 디바이스 플랫폼에 대해서도 공부가 필요하다. 예를들어 안드로이드 플랫폼에서는 adb 를 사용할 수 있다. adb 를 통해 개발중인 소스를 기기로 복사할 수 있고 로그도 곧바로 볼 수 있다.

리모트 디버깅 도구를 활용하라

iOS6 와 OSX Lion 이상의 환경에서는 사용한다면 Safari 브라우저를 통해 웹뷰의 디버깅이 가능하고, 최근의 안드로이드 브라우저도 크롬을 통해 디버그할 수 있다. 위 플랫폼에서 벗어난 경우엔 Weinre 를 사용해보는 것을 추천한다.

한마디로 정리하면 – 가능한 모든 것을 추상화하라.

더 효과적인 피어 코드 리뷰를 위한 여섯가지 방법

Leave a reply

한빛미디어에서 당신의 동료가 더 효과적으로 코드리뷰를 할 수 있게 만드는 여섯 가지 방법 라는 좋은 글을 접했습니다. 그런데 읽다보니 번역문이 이해하기 어려운 점이 많아서 원문을 다시 읽게되었고 요약하게 되었습니다. 아래 그 내용을 공유합니다.

디자이너에겐 크리틱(critique – 비평) 이 있고, 개발자에겐 코드리뷰가 있다.

좋은 비평이란 나쁜 피드백을 좋은 피드백으로 감싼 샌드위치같은 것이 아니다. 좋은 비평을 위해서는 아래 세가지가 필요하다.

  1. 합의된 검토 수단
  2. 리뷰어의 객관성
  3. 자신의 작업물을 객관적으로 바라볼 수 있는 작성자

정량적 검토

논쟁이 생기기 어려운, 대부분 쉬운 결론이 나는 검토. 한쪽은 옳고, 다른쪽은 그르다. 적절한 정량적 검토수단을 가지면 작업물을 적절한 자동화 테스트에 넣으면 되므로 리뷰어들을 자유롭게 함. 예를들면 코딩 규칙을 지켰는지 등이 정량적 검토에 속함.

정성적 검토

의견들로 가득한, 들어보면 모두 옳은, 쉽게 결론이 나지 않는 검토. 매우 어렵기 때문에 정성적 평가 수단을 만드는 것은 시도조차 하지 않는 경우가 많음. 하지만 작성자, 리뷰어 모두의 스킬을 올려줄 만하다. 정성적 평가 수단은 비 전문가인 리뷰어에게 코드에서 어떤 요소를 찾아야 하는지 알려줌.

정성적 검토에는 아래와 같은 질문들이 포함됨:

  • 이 코드가 이 프로젝트에서 사용된 적 있는 패턴을 구현했는지?
  • 이 코드가 다른 상황에서도 사용할 수 있을 정도로 충분히 추상화 되었는지?

커뮤니케이션의 어려움

평가라는 것은 결국 도덕적인 평가와 닮아있음. 좋은 리뷰어는 위에 언급된 평가 방법 내에서 다른 것을 많이 더하지 않고도 피드백을 표현할 수 있음. 이건 결국 작성자들에게 (항상 비슷한 수준으로) 중립적으로 대응할 수 있도록 함.

이론적으로는 리뷰어가 말하는 의도를 작성자는 완벽하게 알아들을 수 있음. 하지만 사람들이 모국어가 아닌 외국어로 읽고 쓰는 경우가 많기 때문에 그런일은 잘 없음. 커뮤니케이션은 어렵고, 특히나 중립적인 커뮤니케이션은 더더욱 어렵다. 사실 중립적인 의사소통은 종종 적대적 편향 – 모호한 의사소통을 적대적으로 해석하는 인간의 특성 – 때문에 망가진다.

유용한 팁들

아래 가이드 라인을 따르기 전에 평가가 적당한 유형으로 이뤄지는지 확인해야함. 일단 커뮤니티가 기능과 광범위한 세부 구현에 대해 동의하면 코드를 작성하고 그 후엔 리뷰가 진행되어야 한다

리뷰 중에는 아래 사항들을 따르는지 확인할 것:

  1. 리뷰를 작업의 영역으로 제한하기. 효율적인 리뷰는 문제에 대해 레이저로 쏘는 것처럼 한다. 추가적인 고려사항이 필요한, 범위를 넘어서는 문제는 여기에 딸린 액션 아이템(이슈트래커의 티켓 같은)으로 만들것.
  2. 리뷰를 특정하기. 특정 라인에 대해, 컴포넌트에 대해서만 언급할 것. 일반적인 문제로 만들지 말고 명확하게 표현할 것.
  3. 리뷰를 실천가능하게 할 것. 리뷰한 것을 어떻게 변경구현할지 매우 명백해야 함. 그렇지 않으면 해당 리뷰는 지울것.
  4. 빠른 시간 내로 리뷰를 전달할 것. 리뷰를 전달하는데 오래걸리면 자신의 작업물을 왜 그렇게 개발했는지에 대해 잊어버리기 쉽다. 필자는 리뷰하는 시간을 동료와 미리 정해 놓고 함께 작업함. 잘 안되는 경우도 있지만 작은 팀에서 효율적임.
  5. 해당 문제에 대해 코더가 소요할 시간을 리뷰의 일부로 고려해야 함. 세줄을 고치는데 몇시간이 소요될 수도 있다. 인내하고 이슈를 해결하는데 시간이 걸릴 수 있음을 인지해야함.
  6. 감사하라. 오픈소스 프로젝트라면 일반적으로 기여자들에게 기여의 의무는 없었다. 특히 직장에서는 정말 싫어하는 프로젝트의 일원이 되어서 일할 것을 강요받는 경우도 있다. 감사하다고 이야기하라. 이 모든 것이 달라질 것이다.

램디스크로 더 빠른 개발환경 구축하기

Leave a reply

최근에 한 웹앱 프로젝트를 완료했다. 이 프로젝트를 진행하면서 램디스크를 오랫만에 사용해보게 됐다.

웹앱은 특히 HTML템플릿을 많이 사용했는데 그 특성상 처음 퍼블리싱된 파일이 너댓개 템플릿으로 분리되는 것이 예사였다. 파일이 많아지면서 프로젝트 내에서 파일이름을 검색해 여는 단순한 작업도 은근히 느려지는 것을 느꼈다. 그리고 파일 내부 검색에도 시간이 오래걸렸다.

처음에는 SSD 로 업그레이드를 해야하는가 고민했지만 마침 얼마전 램을 16GB로 업그레이드 하면서 평소 메모리 사용량이 꽤 많이 남게 되어서 활용하기로 했다.

램드라이브를 사용하게 되면서 파일이름을 검색하든 파일 내부를 검색하든 버벅거림이 전혀 없고 아주 만족하며 사용중이다. 파일을 이용하는 모든 작업이 매우 빨라졌다. git 이 속도가 빠른 이유는 로컬에 저장하기 때문인데 램디스크를 사용하면 브랜치 이동 등이 더 빨라진다.

스크립트 소개

아래 스크립트는 OSX 에서만 동작한다. 램디스크를 만들고, 어플리케이션을 실행하는 부분들이 특히 그렇다. 소스는 http://github.com/elegantcoder/ramdisk 에 있다.

스크립트는 Makefile 로 되어있다. 쉘스크립트를 사용할 수도 있었겠지만 arguments 로 분리하는 것을 해본적이 없어서 섹션을 쉽게 나눌 수 있는 Makefile 을 사용했다.

타겟

start
램디스크를 만들고 하드디스크의 프로젝트 파일을 램디스크로 카피해둔다.
stop
make copy 를 실행하고 램디스크를 제거한다.
sync
주기적으로 make copy 를 실행한다.
apps
작업을 시작하면서 필요한 어플리케이션들을 실행하도록 했다. 나의 경우는 터미널, Sublime Text 와 Source Tree 를 실행하도록 했다.
copy
램디스크의 파일을 하드디스크에 복사하는 작업을 한다. rsync 를 사용해보기도 했는데 잠시 생성했다 지운 파일도 복사되는 경우가 있어서 파일을 삭제하고 다시 넣도록 했다. 특히 git 브랜치 이동시에 문제가 발생하는 경우가 많다. 그리고 새로운 이름으로 복사 후 이름을 바꿔주는 편이 안전하다고 생각해 그렇게 구현했다.

변수

새로 작성시에 변수의 마지막 슬래시에 특히 주의해야 한다.

srcPath
하드디스크 내의 소스디렉토리 이다. ex) ~/Development/project
volumeName
만들어질 램 디스크의 볼륨이름이다. 띄어쓰기 금지
targetPath
램디스크가 위치할 볼륨 디렉토리이다. 수정금지.
projectPath
램디스크내 프로젝트가 위치할 디렉토리이다. 램디스크의 root 디렉토리에는 시스템 파일등이 위치하게 되므로 파일을 복사하기가 좋지 않아 볼륨의 루트에서 한단계 아래 디렉토리에 프로젝트를 위치시켰다.
size
만들어질 램디스크의 크기이다. 단위는 섹터 수이다. 섹터는 512byte 단위이므로 아래 공식을 사용하면된다. (1GB*1024byte^3)/512byte.
syncInterval
초단위로 싱크할 주기를 넣는다. 1200 이라면 20분에 한번꼴이다.
tempDir
파일 복사에 사용할 임시디렉토리이다. 현재 시간의 md5 해시 스트링을 사용하도록 해서 무작위로 생성되도록 했다. 굳이 수정할 필요는 없다.

참고

자바스크립트의 변수형을 알아내는 다른 방법

Leave a reply

JavaScript 의 변수형을 알아내는 데는 일반적으로 typeof 를 사용한다. 하지만 toString 을 사용하면 어떤 객체의 인스턴스인지까지 한번에 알아낼 수 있다.

JavaScript 의 변수형을 알아내는 데는 일반적으로 typeof 를 사용한다.

이 방법이 가장 간단하고 일반적인 방법이다.

typeof 가 나타낼 수 있는 변수형은 아래와 같다. undefined, object, boolean, number, string, function, object

typeof 가 변수에 대한 기본적인 호기심을 해결해주긴 하지만 몇가지 모자란 점이 있다. 가장 큰 문제는 어떤 객체의 인스턴스인지 정확히 알려주지 않는다는 점이다.

typeof null 은 ‘object’ 이다.

typeof null === 'object'; // true

typeof [] 도 ‘object’ 이다.

typeof [] === 'object'; //true

따라서 어떤 객체인지 더 알아보려면 조건판단을 더 해주어야 한다. 예를들면 날짜 객체인지 알아보려면 아래처럼 구현하기도 한다.

var date = new Date();
if (typeof date === 'object' && date instanceof Date) {
    console.log 'date';
}

instanceof 는 같은 윈도우 환경에서만 작동하므로 위 방법은 프레임/아이프레임/팝업 같은 환경에서는 실패한다.

다른 방법

변수형을 알아내는 다른 방법도 있다. 바로 .toString() 을 사용하는 것이다.

Object.prototype.toString.call({}) === "[object Object]" //true

이 방법은 객체 타입까지 구체적으로 표현해주는 장점이 있다.

Object.prototype.toString.call(new Date) === "[object Date]"; //true
Object.prototype.toString.call(/s/) === "[object RegExp]"; //true
Object.prototype.toString.call(/null/) === "[object Null]"; //true
Object.prototype.toString.call(1) === "[object Number]"; //true

어떤 원리인지 자세히 알아보고 싶다면 참고링크의 Fixing the JavaScript typeof operator 항목을 참조하기 바란다.

underscore.js 에서는 아래와 같이 사용하고 있다.

  // Add some isType methods: isArguments, isFunction, isString, isNumber, isDate, isRegExp.
  each(['Arguments', 'Function', 'String', 'Number', 'Date', 'RegExp'], function(name) {
    _['is' + name] = function(obj) {
      return toString.call(obj) == '[object ' + name + ']';
    };
  });

성능문제

하지만 이 방법의 단점은 성능이다. 사실 프로토타입의 객체를 call로 부르는 구현법이 typeof 라는 연산자보다 성능이 좋을리가 만무하다. 참고링크에 JSPerf 항목에서 underscore의 이전 구현/현재 구현간의 성능차이를 확인할 수 있다.

성능문제에도 불구하고 객체의 타입까지 손쉽게 알아낼 수 있으므로 효율적인 개발을 가능하게 할 것이고, 이 방식의 매우 큰 장점이다.

참고링크