25 9 / 2014

"

dry!
$ mkdir -p test/{entry1,entry2,entry3}
$ touch !!:2/{index.js,package.json}

it means
$ touch test/{entry1,entry2,entry3}/{index.js,package.json}

cool

"

23 9 / 2014

common.js 모듈러 패턴을 사용할 수 있게 해 주는 broweserify 툴에 대한 소개. 공식 홈페이지에서 오늘까지 소개된 내용을 살펴 봄.

http://browserify.org/articles.html

소개/기본

Browserify Handbook

github.com/substack/browserify-handbook

제작팀 Substack 에서 소개하는 핸드북, 쭉 읽어 보면 된다.

Introduction to Browserify

superbigtree.tumblr.com/post/54873453939/introduction-to-browserify

심플한 예제를 통해 브라우저리파이와 버피를 소개하고 있다. 해당 원고는 저자가 참여한 이북의 원고로 사용되고 있다고 한다.

Untangle Your JavaScript with Browserify

lincolnloop.com/blog/untangle-your-javascript-browserify

클라이언트 자바스트립트 개발 ‘이래서는 안된다.’ 라는 말로 브라우저리파이와 프랜스폼에 대해 소개하고 있다.
역시 심플한 코드와 그런트와 걸프를 함께 사용하는 코드를 소개하고 있으니 꼭 보길 추천.

How Browserify Works

benclinkinbeard.com/posts/how-browserify-works

조금 어려운 얘기들이 시작된다. IIFE 에 대한 이야기를 하며 브라우저리파이를 설명하고 있다. 엄청나게 복잡하고 놀라운 것들이 있지만 결론은 엄청나게 많은 NPM 모듈들을 브라우저리파이를 통해 사용할 수 있다는 것이라고 알려준다.
추가로 아토미파이에 대한 포스트도 눈여겨 볼 만하다.

Browserify: Unix In The Browser

thinkingonthinking.com/unix-in-the-browser

거창한 제목과 다르게 심플한 설명을 통해 브라우저리파이를 소개한다. 유닉스니까 심플하게 소개하는게 맞나? 커멘드 라인이여 영원하라.

Sharing code between Node.js and the browser

blog.codecentric.de/en/2014/02/cross-platform-javascript

CommonJS 와 RequireJS, AMD 에 대한 이야기로 장문은 시작한다. 코드의 규모가 커질수록 모듈러, 코드 로더, 로더와 브라우저, 서드파티 코드, 백엔드와 프론트엔드에 대한 효율이 논의된다. 그에 대한 해결책으로 제시하는 것이 브라우저리파이다.
그런트 매니저와 와치파이를 통해 사용하는 법을 설명하고 있다. 노드 모듈이 모두 브라우저에서 돌아가지 않기 때문에 필요한 시밍 코드들에 대해서도 얘기한다.

Using npm on the client side

dontkry.com/posts/code/using-npm-on-the-client-side.html

NPM 의 위대함을 다시 한번 이야기 한다. 그리고 그걸 브라우저에서도 사용하는 브라우저리파이에 대해 소개한다. 콘솔에서 이 모든 작업을 한 번 해보고 그런트를 통해 한방에 처리하는 법을 설명하고 있다.

NPM Everywhere (Slides)

[NPM Everywhere][http://slid.es/azer/npm]

지금까지 게시물을 잘 봤으면 으흠 하고 지나갈 내용들.

Node Packaged Modules, bringing npm modules to the web

maxogden.com/node-packaged-modules.html

역시 NPM 에 대한 이야기와 브라우저에서 NPM 을 사용한다는 이야기. 브라우저리파이된 코드를 CDN 하는 위저드.인 사이트를 소개한다. 그리고 RequireBin 을 소개하고 있다. JSBin 에 익숙하다면 감 잡을 수 있다. RequestBin 의 예제 코드를 보면 이게 내가 알던 프론트엔드 코드인지 헷갈린다.
이후 npmsearch 를 소개하는데 일레스틱서치를 사용하고 있어 참고할 코드가 있을 것이라 생각된다. 그리고 쿨한 예제들을 소개하고 있다.

Browserify and the Universal Module Definition

dontkry.com/posts/code/browserify-and-the-universal-module-definition.html

지금도 자바스크립트 월드에서 모듈링은 현재 진형형이다. ES6 에 도입되는 기능도 링크되어 있다. 모듈화에 대한 문제점과 컨셉 코드 그리고 브라우저리파이, AMD, ES6 에 대해 이야기한다.

Standalone Browserify Builds

www.forbeslindesay.co.uk/post/46324645400/standalone-browserify-builds

브라우저리파이를 통해 스탠드얼론 라이브러리를 만드고 그걸 사용하는 샘플 코드. 새로울 것도 없다.

Browserify v2 adds source maps

thlorenz.com/blog/browserify-sourcemaps

소스 맵에 대한 소개 링크를 던저 준다. 브라우저리파이 작업시 소스맵을 추가로 생성하는 옵션인 —debug 항목을 보여주면서 이야기를 풀어간다.

Browserify on Small.js

smalljs.org/package-managers/npm/browserify/

노드 기반의 NPM 을 브라우저에서 사용하는지에 대한 얘기. 하나의 번들로 묶어 버리는 특성 때문에 소스맵을 사용하라는 얘기. 자동화 도구들. jQuery 를 비롯한 유명 프레임워크들도 npm 으로 설치할 수 있다. 왜냐면 브라우저리파이로 사용할 수 있게 되었기 때문이다.

사용법

A Year With Browserify

aeflash.com/2014-03/a-year-with-browserify.html

그런트 짱, 노드 모듈 짱, 모듈 관리에 대한 이야기르 풀어간다. 리얼월드에서 벌어지는 씨밍, 시밍이 포함된 빌드, 디펜던시 문제, 파일 경로 문제 등에 대해 소개하고 있다.

Using angular and grunt with browserify

dontkry.com/posts/code/angular-browserify-grunt.html

앵귤러와 브라우저리파이 그리고 그런트 템플릿

Basics of making maps with leaflet.js and browserify

learnjs.io/blog/2013/11/08/leaflet-basics/

Leaflet.js 를 중심으로 브라우저리파이, 버피를 사용해 앱을 만든다. 몇가지 지도 관련 테크닉들이 소개되어 읽어볼 가치가 있다.

Backbone & jQuery meet Browserify: easy.

learnjs.io/blog/2013/11/23/backbone-jquery-browserify

jQuery 와 백본을 사용한 튜토리얼 특히 jQuery 2.1 부터 좀 더 쉽게 브라우저리파이를 사용할 수 있다.

Grunt+browserify+npm+application=success

codeofrob.com/entries/grunt+browserify+npm+application=success.html

브라우저리파이와 그런트를 사용하는 프로젝트 초기 단계를 위한 셋업을 보여주고 있다.

gulp browserify starter faq

viget.com/extend/gulp-browserify-starter-faq

걸프 사용자를 위한 코드 템플릿. 코드로 말하는 튜토리얼 좋다.

관련 툴

Beefy

http://didact.us/beefy/

grunt-browserify

https://github.com/jmreidy/grunt-browserify

chem

캔버스를 사용하는 게임엔진 툴킷
https://github.com/superjoe30/chem/

비슷한 목적의 툴과 비교

Journey from RequireJS to Browserify

esa-matti.suuronen.org/blog/2013/03/22/journey-from-requirejs-to-browserify

RequireJS 에서 브라우저리파이로 옮긴 프로젝트 담당자의 글. 내가 이 글을 쓰게 된 계기가 된 포스팅.

2013: A client side package manager oddyssey

calvinmetcalf.com/post/61957209713/2013-a-client-side-package-manager-oddyssey

Browserify vs. Component

www.forbeslindesay.co.uk/post/44144487088/browserify-vs-component

리소스

Browserify documentation/github repository

https://github.com/substack/node-browserify#browserify

Art Of Node - How Require Works

https://github.com/maxogden/art-of-node/#modular-development-workflow

node.js modules documentation

http://nodejs.org/docs/latest/api/modules.html#modules_modules

Packages tagged with browserify on npm

https://npmjs.org/browse/keyword/browserify

Browserify on StackOverflow

http://stackoverflow.com/questions/tagged/browserify

비디오

Browserify V2 and you

http://vimeo.com/62988591

Modular JavaScript With Npm And Node Modules

http://ericleads.com/2014/03/modular-javascript-with-npm-and-node-modules/

테스팅

How I Write Tests for Node and the Browser

substack.net/how_I_write_tests_for_node_and_the_browser

역시 서브스택의 좋은 글. 테스트는 중요하다.

22 9 / 2014

윈스톤과 번얀에 대해 스트롱루프에서 비교한 글이 있어 참고했다.
http://strongloop.com/strongblog/compare-node-js-logging-winston-bunyan/

콘솔

가장 원시적인 로그 방법인 console.logconsole.error 를 통해 기본 출력과 기본 에러를 로깅 할 수 있다. 바로 쓰기 편하나 체계적이지 못하면 역시 가장 골치하픈 상태가 되어 버린다. 콘솔 로그의 경우 메모리 점유가 조금씩 일어나 서버 프로그램의 일부분으로 쓰기엔 만족스럽지 못하다.

윈스톤

스트롱루프에서도 인정하는 가장 유명한 로깅 프레임워크. IRC 채널 출력도 지원하는 등 다양한 로그 출력을 제공한다.

var winston = require('winston');
winston.log('info', 'Hello distributed log files!');
winston.info('Hello again distributed logs');
info: Hello distributed log files!
info: Hello again distributed logs

번얀

윈스톤보다 좀 더 고민한 흔적이 있는 로깅 프레임워크라고 생각한다고 한다. 기본으로 JSON 출력을 하고 있는 등 윈스톤과 조금 다른 접근을 하고 있다. 차일드 프로세스를 생성해 별도 그룹으로 로깅을 할 수도 있다. 다른 모듈과 함께 작동해야하는 로그 시스템으로 좀 더 나은 접근이다. 스트롱옵스 같은 프로젝트에는 번얀이 더 적합하다고 생각한다.

var bunyan = require('bunyan');
var log = bunyan.createLogger({name: 'myapp'});
log.info('hi');
log.warn({lang: 'fr'}, 'au revoir');
{"name":"myapp","hostname":"pwony-2","pid":12616,"level":30,"msg":"hi","time":"2014-05-26T17:58:32.835Z","v":0}
{"name":"myapp","hostname":"pwony-2","pid":12616,"level":40,"lang":"fr","msg":"au revoir","time":"2014-05-26T17:58:32.837Z","v":0}

19 9 / 2014

그래픽 툴 관련 소식 정리

Xcode 업데이트 하러 맥 앱스토어 들렸다가 에디터 초이스에서 익숙하지만 이곳엔 낯선 이름을 발견하고 궁금해 관련 정보들을 추적했다.

오토데스크 퓨전 360

오토데스크 퓨전 360 이란 인터렉티브 한 모델링 툴을 보았다.
360 시리즈는 오토데스크 클라우드 플랫폼을 의미하는 것 같다. 오토데스크 360 이란 타이틀로 많은 검색어가 걸러졌다.
캐주얼한 인터페이스로 3D 디자이너에게 매달 입금하라고 꼬시고 있다. 튜토리얼 영상을 보면 느끼겠지만 상당히 직관적이다. 구글이 인수했다가 다시 독립한 스캐치업3D 의 느낌도 난다. 1달 무료 사용에 매달(또는 연간) 일정 비용으로 사용 할 수 있도록 되어 있다. (무료가 아니라 그냥 블렌더 쓰기로…)

Fusion 360 Tutorial

더 펀더리 누크

홈페이지에는 누크, 누크X, 누크STUDIO 버전이 소개되고 있다.

  • 누크 : 최고 수준의 2D 합성 파이프라인, 멀티 채널 워크플로우, GPU 가속, 파이썬 스크립팅
  • 누크X : 더 강력한 트래킹(3D), 파티클 시스템, 이미지 클리닝, 렌즈 디스토션, 협업
  • 누크STUDIO : 넌리니어 편집 툴이 들어간 라인업 2014년 말에 소개된다고 함

좀 더 보다보니 누크 9 테크니컬 프리뷰가 있다. 내년에 나올 듯 하다.

펀더리는 모도(라이트웨이브 개발팀 일부가 회사를 나온 후 창업)를 인수 후 다양한 제품을 선보이고 있다. 최고의 합성 플러그인을 개발하던 회사가 최고의 합성 툴을 내놓은 후 최고의 3D 기술을 흡수한 다음 내놓는 결과물이라 이해가 된다. 누크 9 이 기대된다. (물론 내가 쓸 일은 없지만…)

Nuke Studio

망가 스튜디오 EX 5

모든 디지털 만화가의 친구가 되고 싶은 망가 스튜디오가 버전 5 를 판매하고 있다. 일반 버전과 EX 버전으로 구분되어 소비자를 유혹한다. EX 버전은 페이지 레이아웃 관련 기능이 추가 되어 있다.(물론 이것도 쓸 일이 없지.)

Manga Studio 5 EX

시네마 포디 R16

얘넨 뭔 업데이트가 이리 빠르냐! 아 일년에 한 번씩 정상인건가? 아무튼 시포디 16 이 현재 버전이다. 얼마 전 블렌더에서 본 모션 트래킹 기능이 내장 되었나보다. 몇 가지 신 기능과 개선이 있지만 시포디 수준이면 더 이상 뭐 발전할 것도 없다. 이미 완성형. (역시 난 쓸 일 없다.)

Cinema 4D R16

17 9 / 2014

@npmjs pro tip:

"npm install —save async" == "npm i -S async"
"npm install —save-dev mocha" == "npm i -D mocha"

https://twitter.com/Ask_11/status/506879600727949312

16 9 / 2014

마크다운을 기반으로 또는 마크다운 컨셉을 차용한 온라인/오프라인 글쓰기 도구들에 항상 관심을 두고 있는 입장에서 최근 가장 모범적인 또는 주목할 만한 솔루션에 대한 노트를 남겨본다.

그간 editorially, documently, prose.io 를 눈여겨 보다 에디토리얼리와 도큐멘틀리는 서비스를 접업다. 그 외 참고하는 서비스들은 다음과 같다.

펜플립

가장 상업적 완성도가 높게 나온 서비스는 펜플립이다. 글쟁이를 위한 Git 서비스로 홍보되어 알게 되었는데 가장 완성도가 높다.

유료 모델이 있는데 아직 수익이 나는 것 같아 보이지 않는다. 프라이빗 계정으로 세팅해도 과금에 대한 이야기가 없다. 물론 제대로 사용해보지 않아서 그럴 수도 있다.

코드미러를 기반으로 하고 있으며 마크다운 프리뷰를 위한 커스텀이 들어가 있다. 한글 입력도 잘 되고 글쓰기 환경도 잘 갖추어져 있다.

깃북

그리고 무료 모델로 좋은 성장을 하고 있는 깃북의 경우 한글 환경이나 에디팅 환경이 매끄럽지 못하다.

ACE 에디터를 기반으로 하고 있으며 노드 웹킷으로 패키지되어 있다. 소스가 공개되어 있어 벤치마크에 도움이 될 수도 있겠다.

드래프트

최근 발견한 멋진 에디터, 버전관리, 코멘트 등 기본기가 아주 충실하다. 파일 업로드 및 이미지 링크가 인상적이다. 에디터 소스 베이스가 뭔지 아직 파악하지 못했다.

작성된 글을 전문가에게 검토 받는 방법으로 수익을 창출하고 있는듯 하다.

아직 큰 홍보가 되지 않고 있으나 각종 서비스 연동이 아주 확실하고 이메일로 글을 저장하는 큰 기능들부터 블럭 영역의 계산을 실행해주는 등의 소소한 기능까지 참신한 아이디어가 좋다.

16 9 / 2014

Titanium CLI 모드 작업시 사용한 명령들

npm -g install titanium

ti

ti login

ti sdk list

ti sdk install

ti setup

npm -g install alloy

ti create —name=dota2handbook —id=com.nomodem.dota2handbook

cd dota2handbook

alloy new

ls -al

use `https://github.com/riteshdalal/jsca2js`

./titanium-mobile.py 3.3.0

ls titanium-js

embed this .js file to webstorm project

참고

http://unbounded.io/post/56849030130/titanium-workflow-maximize-your-productivity

15 9 / 2014

http://blog.risingstack.com/from-angularjs-to-react-the-isomorphic-way/

몇 가지 이유로 NG 에서 최종 React + Flux + Node.JS (Koa) 로 스택을 변경한 RisingStack 사의 블로그.

내가 웹을 바라보는 관점에서 웹 앱은 여전히 먼 곳이다. 웹 앱이 SEO 에 대한 대비가 부족한 것도 맞다. 이런 저런 제한을 모두 제거하고 서비스를 하고 싶다면 node-webkit 같은 좋은 것이 있다고 본다.

웹은 여전히 문서가 중심이 되어야 한다고 보고 있고 그에 맞는 서비스를 하는 것이 옳다고 생각한다.

NG 는 너무 verbose 한 느낌이 많다. $ 사인도 그렇고 예쁘지 않다. 오히려 Ember.JS (SproutCore) 나 Knockout.JS 같은 것이 나아 보인다.

15 9 / 2014

http://strongloop.com/strongblog/node-js-v0-12-shell-programming-synchronous-child-process/

Node.JS 를 만들고 있는 Strong loop 의 소식.

비동기를 기본으로 하는 node 에서 쉘 스크립트 대체용으로 코드를 만들기에는 뭔가 좀 부족했던 것은 사실이다. 이에 노드 0.12 에서 매력적인 모듈이 추가된다. (이미 0.11 에서는 사용 가능하다.)

수 많은 npm 을 통한 모듈들과 함께 쉘 스크립트도 자바스크립트로 정복!
예제 코드만 봐도 아주 맘에 든다. 함께 소개한 아래 링크의 코드도 참고.

http://strongloop.com/strongblog/whats-new-in-node-js-v0-12-execsync-a-synchronous-api-for-child-processes/

15 9 / 2014

http://www.htmlxprs.com/post/14/superpower-your-javascript-with-10-quick-tips

  1. && 연산자와 || 연산자를 잘 사용해라.
    명시적인 표현이 크게 중요한 것이 아니면 이렇게 짧게 사용하는 편이 나아 보인다. C 스타일의 표현법을 가지는 많은 언어들이 이런 식으로 코딩하는 것을 지원한다.
  2. == 나 != 를 사용하기 보다는 === 나 !== 를 사용해라.
    의도를 알고 있다면 크게 문제되지 않는다고 본다. 성능면에서 어떤 이점이 있는지 모르겠지만 (큰 영향은 없을 거라고 본다. 타입 변환이 일어나니 영향이 없지는 않다.) 의도치 않은 버그나 스펙이 명확히 준비되어 있는 환경에서 공동작업을 한다면 지켜주는 편이 좋다고 본다.
  3. Strict 모드를 사용해라.
    나도 아직 ‘use strict’ 지시자를 써본 적이 없다. IDE 에서 적당한 수준의 가이드를 제공하고 있고 jslint, jshint 등의 프로세스를 거친다면 코드 퀄리티에는 큰 의미가 없지 않을까 싶다. 하지만 엄격한 엔진을 세팅하는 역할을 하니 충분히 사용하는 것도 좋다. 개인적으로 어노테이션 류를 좋아하지 않아서 안썼다고 변명을…
  4. 배열 조작 시 delete 대신 splice() 를 사용해 보라.
    어레이 작업할 때는 어레이 전용 메소드를 사용하는 편이 좋다. 많은 사람들이 new 객체 생성 대신 리터럴 객체 생성을 권유하는 것과 같은 이유다.
  5. 객체 생성시 리터럴을 사용하라.
    보기에도 좋고 스타일을 유지하는 것에도 좋다.
  6. String.link() 메소드를 사용하자.
    이건 정말 몰랐다. 강력 추천!
  7. 루프에서 캐쉬를 사용하는 것은 기본.
    for (var i=0,length=array.length;i<length;i++) {
      //awesome code goes here
    }
    이렇게 사용하는 것은 코딩 스타일도 크게 해치지 않아 좋다.
  8. 글로벌 변수 사용을 자제하자.
    의도적으로 필요한 경우도 있다.
  9. 클로저와 즉시 실행 함수를 사용하자.
    변수가 오염되는 것도 방지하고 적절한 캡슐화로 좀 더 나이스한 코드가 된다.
    “`
    var
    car=(function() {
        var _name='Benz Velo';
        return {
            getName:
    function() {
                return _name;
            }
        }
    })();
    //function created and invoked
    console.log(car.getName());
    //Logs Benz Velo
    “`
    어느 부분에 캡슐화가 필요한지 선택, 결정 하는 것도 내공이 필요하다.
  10. 코드 압축화에 신경쓰자.
    jsHint 나 jsLint 도 돌려주고 minify 와 concat 을 통해 자바스트립트 코드를 압축한 후 배포하는 것이 항상 좋다. 물론 개발 단계에서는 권장 사항.