무하프로젝트

Git 저장소 파일 분석(Blob 형식)

1. Header 형식을 포함하여 Zlib으로 압축되어 저장된다.

- Header 형식: "Blob/원본 파일크기/null" > "blob(객체 종류) 11(원본 파일 크기)\x00(null 바이트) some-value\n"

- 실제 이전 포스트에서 생성된 C1(첫 번째 commit 객체)에 대한 파일 뷰는 아래와 같다.

- Git는 내부에서 생성되는 모든 파일을 단순 이름이 아닌 SHA-1 Hash(902640....8a) 방식으로 저장한다. 이는 16진수 문자로 조합된 40개의 문자열로 파일의 내용 및 해당 디렉터리 구조를 바탕으로 구성되어진다.

- 보안 상 오직 Git를 통해서만 원하는 파일에 접근 및 수정이 가능하다.

- AJ 님의 "Advanced Git" 슬라이드(참고 슬라이드)

Git HEAD Pointer 및 Branch Pointer 설명

1. Git 명령의 대부분은 File 보다는 Commit 객체를 다룬다.

2. Git 에서의 HEAD와 Branch는 Pointer임을 기억하자.

1. C1(첫 번째 commit 객체) 생성 후 HEAD Pointer 및 Branch Pointer의 변화

- C1(첫 번째 commit 객체) 생성 후 HEAD Pointer는 기존 master Branch를 가리키며, 해당 branch(master) Pointer는 C1(첫 번째 commit 객체) Pointer를 가리킨다.

2. C2(두 번째 commit 객체) 생성 후 HEAD Pointer 및 Branch Pointer의 변화

- C2(두 번째 commit 객체) 생성 후 HEAD Pointer는 기존 master Branch를 가리키며, 해당 branch(master) Pointer는 C2(두 번째 commit 객체)를 가리킨다.

3. C3(두 번째 commit 객체) 생성 후 HEAD Pointer 및 Branch Pointer의 변화

- C3(세 번째 commit 객체) 생성 후 HEAD Pointer는 기존 master Branch를 가리키며, 해당 branch(master) Pointer는 C3(세 번째 commit 객체)를 가리킨다.

4. 새로운 Branch(develop)를 생성 후 HEAD Pointer 및 Branch Pointer를 각각 develop Branch와 C2(두 번째 commit 객체)를 가리키도록 만든다

HEAD > develop Branch

develop Branch > C2(두 번째 commit 객체)

- AJ 님의 "Advanced Git" 슬라이드(참고 슬라이드)

Git 저장소 분석

- Git 저장소는 아래와 같은 구조로 구성되어있다.

1. Working 영역(작업 폴더)

- "git init" 명령 실행 후 ".git" 파일이 저징되어 있는 위치를 가리킨다.

2. Staging 영역

Working 영역(작업 폴더)에 임의의 파일(Readme)을 생성 후 "git add ." 명령을 통해 Staging 영역으로 추가 시킨다.

또한, Working 영역의 Readme 파일은 "Blob" 형식으로 변환되어 아래 경로(.git/objects/3e/d8....79)에 저장되며, 파일의 실제 내용은 "Zlip(데이터 압축 라이브러리의 일종)"으로 압축되어 있다.

git add . 명령은? 

- Git로 하여금 앞으로 이 파일을 Tracking 하겠다는 선언이며, 다른 VCS(Version Control System) 시스템과는 달리 "commit" 단계가 아닌 "add" 단계에서 저장소에 파일이 생성되는 것을 볼 수 있다.

3. Repository 영역

"git commit" 명령을 통해 이전 Staging 영역에 등록된 리스트를 참조(add 명령을 통해 이미 Staging 영역에 파일이 등록되어 있기 때문)하여 새로운 "commit object"를 생성한다.

또한, 생성된 "commit object"는 아래 경로(.git/objects/48/c468937...72)에 저장되며, "Zlip"을 통해 압축된 내용을 확인 시, 아래와 같이 "Tree, Author, Committer, Commit msg" 가 담긴 내용을 확인할 수 있다.

.git/refs/heads/master 파일은 아래와 같이 "486893....72" commit object 객체를 가리키고 있다.

4. 두 번째 commit object 생성 후 HEAD 변화

- 위 과정을 통해 두 번째 "commit object" 까지 생성하게되면, 이전 "486893....72" 객체를 가리키던, .git/refs/heads/master 파일은 새로운 commit object인 "786481...60" 객체를 가리키게 된다.

이는 "git branch -v" 명령을 통해서도 확인 가능하다.

5. Git 저장소 내부 파일의 Status Life Cycle은 아래 같으며, 보시는 바와같이 파일의 Untrancked 시점과 Tracked 시점은 Git add 전/후로 나눠진다.(중요!!)

출처: http://www.slideshare.net/andabi/git-16126636

- AJ 님의 "Advanced Git" 슬라이드(참고 슬라이드)

만약 JQuery와 같이 외부에서 공개된 오픈 소스 라이브러리들을 사용하고자 할때 보통 우리는 아래와 같은 방법으로 해당 정적 리소스들을 Include 시킨다.

< script type="text/javascript" defer="defer" src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.0/jquery.min.js">

하지만 만약 어플리케이션의 도메인이 HTTPS(보안 통신 프로토콜(SSL 적용))를 사용하는 경우라면, 위 코드와 같이 삽입할 경우 아래와 같은 문제가 발생한다.

- 아래 그림에서 보시다시피 크롬 개발자 도구의 네트웍 탭 상에 Include 시킨 리소스(jquery.min.js)가 없는 것을 확인할 수 있다.

- 또한, 콘솔 탭을 살펴보면 아래와 같은 오류(안전하지 않은 컨텐츠이기 때문에 가져올 수 없다?)를 확인할 수 있다.

위와 같은 문제를 간단히 해결하기 위한 방법으로 아래 코드와 같이 Include 블럭 속성 값(url)을 넣어준다. 

- 이와 같이 정의할 경우 해당 어플리케이션의 HTTP 프로토콜에 따라 속성 값의 Protocol이 자동 변환되기 때문이다.

즉, 어플리케이션 상의 프로토콜이 HTTP라면 "http"로 HTTPS라면 "https"로 자동 변환되는 것이다.(P.S: IE6 ~ IE10 or 표준 브라우저 호환)

< script type="text/javascript" defer="defer" src="//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js">

- 아래 그림은 위 코드 블럭을 적용한 결과이다.

- 만약 리소스들을 Include 하는 파일(html)이 로컬 웹 서버를 거치치 않는 방식(직접 파일 열기)일 경우 위와 같은 선언 방식(//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js) 으로는 해당 리소스들이 열리지 않는다.

즉, 간단한 테스트를 위해 생성한 html 파일을 위와 같은 방법으로 리소스들을 인클루드 시킬 경우 에러가 발생하니 사용 시 주의해야할 필요가 있다.

PS: 또한, 개발자 도구를 통해 살펴본 리소스들의 주소는 아래와 같다는 것을 알수 있다.

file://ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js

- 출처: @insanehong님

참고사이트:

https://developers.google.com/speed/libraries/devguide

http://hoons.net/Blog/View/111726

1. MVC 패턴이란?

MVC 패턴이란 하나의 어플리케이션을 크게 Model, View, Controller이라는 세 영역으로 구분하고 각 영역간의 코드 결합도를 최소화 시키는 개발 패턴 중 하나이다.

- 다시말해 패턴의 주요 목적은 Model과 View 영역간의 코드 결합도를 최소화 시키는데 있다고 볼 수 있다.

2. 영역간의 역활 정의

Model: 어플리케이션에 비지니스 로직과 사용되는 데이터를 다루는 영역이다.

- 보통 비지니스 로직에 필요한 데이터는 해당 DB에 의해 관리되고, 그 데이터를 다루는 연산은 SQL 문법을 통해 구현된다.

View: 최종 사용자에게 보여줄 프리젠테이션 로직을 담당하는 영역이다.

- 웹으로 말하자면 정적 리소스로는 HTML, 동적 리소스로는 ASP, PHP, JSP 등의 파일로 나뉠 수 있다.

Controller: 기존 MV 패턴에서 View가 맡아하던 Model 영역과의 일부 로직들을 Controller 영역으로 대체하여, Model과 View 영역간의 코드 결합도를 줄여주는 영역이다.(결국 패턴의 궁극적인 목적을 이루기 위한 가장 중요한 영역이라고 볼 수 있다.)

3. 영역간의 진행 순서

사진출처: http://cheucheu.tistory.com/48

- 이전 MV 패턴과는 상대적으로 복잡한 구조를 지닌 것을 것을 볼 수 있으며, 패턴에 대한 진행 순서은 아래와 같다.

1. Client(최종 사용자)가 특정 Controller 영역을 호출한다.

2. 요청받은 Contoller 영역은 특정 Model 영역의 비지니스 로직을 호출해 그에 대한 수행 결과(보통 DB 연동을 통한 데이터들의 집합이다)를 반환받는다.

3. Controller는 Model 영역을 통해 반환받은 데이터들의 집합을, 특정 View를 호출해 클라이언트에게 응답(제공)할 UI를 만들도록 한다.

- 패턴 진행 순서: Controller >> Model >> Controller >> View

- 장점: 

1. 어플리케이션 유지보수 시 비지니스 로직에 대한 변경 사항이 많은 경우 추가되는 개발 비용이 현저히 내려간다.(Contoller 영역을 통해 Model과 View 영역간의 코드 결합도를 현저히 낮춤으로써 Model 영역의 비지니스 로직 변경 시 해당하는 View 영역의 변경 사항이 줄어든다.(하지만 이는 아래 단점에서도 볼 수 있듯이 Controller 영역을 어떻게 설계하느냐에 따라 크게 달라질 수 있는 부분이기도 하다.))

2. Contoller 영역을 통해 전체 어플리케이션 코드 관리가 용이해진다.(이는 위 장점과 마찬가지로 유지보수 시에 대한 또 다른 장점이며, 결국 이 또한 Model과 View 영역간의 코드 결합도를 낮춤으로써 나타나는 결과이다.)

- 단점: 

1. 이전 MV 패턴과는 달리 좀더 복잡한 개발 구조를 통해 초기 개발 비용이 올라간다.(단순히 생각해도 이전에 없었던 Contoller 영역의 추가로 인해 초기 개발 비용이 상승하는것은 너무도 당연한 일이다.  다시말해 영역들간의 좀더 세밀한 역활 분기로 인해 설계 및 작성해야 할 코드량이 많아진다는 것이다.)

2. 앞서 말했듯이 MVC 패턴의 복잡한 아키텍처로 인해 각 영역에 대한 재 사용성은 이전 MV 패턴에 비해 많은 부분 좋아졌지만, 그 만큼 새롭게 추가되는 Contoller 영역의 역활이 중요해졌으며, 만약 개발이 잘 못 되었을 경우 어플리케이션 전체에 미치는 악 영향이 매우 커질 수 있다.

4. JavaScript로 구현한 MVC 패턴의 예

- 화면 UI는 이전 MV 패턴과 동일하며, 아래 작성된 패턴에 대한 설명은 코드 상 주석으로 표기하였다.

참고 사이트:

MVC(Model / View / Controler) 패턴:

http://blog.naver.com/yellobox62?Redirect=Log&logNo=80048634644

1. MVC 패턴이란?

MVC 패턴이란 하나의 어플리케이션을 크게 Model, View, Controller이라는 세 영역으로 구분하고 각 영역간의 코드 결합도를 최소화 시키는 개발 패턴 중 하나이다.

- 다시말해 패턴의 주요 목적은 Model과 View 영역간의 코드 결합도를 최소화 시키는데 있다고 볼 수 있다.

2. 영역간의 역활 정의

Model: 어플리케이션에 비지니스 로직과 사용되는 데이터를 다루는 영역이다.

- 보통 비지니스 로직에 필요한 데이터는 해당 DB에 의해 관리되고, 그 데이터를 다루는 연산은 SQL 문법을 통해 구현된다.

View: 최종 사용자에게 보여줄 프리젠테이션 로직을 담당하는 영역이다.

- 웹으로 말하자면 정적 리소스로는 HTML, 동적 리소스로는 ASP, PHP, JSP 등의 파일로 나뉠 수 있다.

Controller: 이 포스트에서 다루는 코드들은 MV 패턴으로만 구현할 것이기에 이번 포스트에서는 Controller 영역은 설명하지 않겠다.

3. 영역간의 진행 순서

사진출처: http://cheucheu.tistory.com/48

- 위 그림은 초기 웹 개발 시(하지만 현재도 많이 사용되고 있는 개발 패턴 중 하나이다) 많이 사용되던 패턴이며, 패턴에 대한 진행 순서은 아래와 같다.

1. Client(최종 사용자)가 특정 View(HTML, ASP, PHP, JSP) 영역을 호출한다.

2. 요청받은 View 영역은 특정 Model 영역의 비지니스 로직을 호출해 그에 대한 수행 결과(보통 DB 연동을 통한 데이터들의 집합이다)를 반환받는다.

3. Model 영역을 통해 반환받은 데이터를 가공하여, 클라이언트에게 응답(제공)할 UI를 생성한다.

- 패턴 진행 순서: View >> Model >> View

- 장점: 프로젝트 유지보수 시 비지니스 로직에 대한 변경 사항이 많지 않은 경우 개발 비용이 상대적으로 적게든다.(사실 아무리 작은 프로젝트라 하더라도 이런 경우는 흔하지 않다.)

- 이 말은 View에 대한 특정 컨트롤을 따로 작성할 필요가 없으므로 상대적인 개발 비용이 적게 든다는 말과 같다.(단 이는 MVC 패턴에 대한 상대적 예라는 것을 염두해야 한다.)

- 단점: View와 Model 영역간의 결합도가 상당히 높아 View 영역의 재활용성이 떨어진다.(Model 상의 비지니스 로직 변경 시(프로그램 설계 변경/추가/삭제 시) 그것들을 호출하는 각 View의 프리젠테이션 로직들을 전부 수정해야한다.)

4. JavaScript로 구현한 MV 패턴의 예

- 아래 작성된 패턴에 대한 설명은 코드 상 주석으로 표기하였다.

참고 사이트:

MVC 패턴이란?

http://cheucheu.tistory.com/48

http://blog.loveciel.kr/58

얼마 전 활동 중인 그룹(undefinedD)에 새롭게 올라온 글을 본 후 JS 생성 패턴에 대해 나름 다시한번 정리해 보는 시간을 가졌다.

먼저 아래는 그룹에 올라온 글에 대한 전문이다.

1. JQuery 객체 생성 패턴

- 아래는 실제 JQuery 코드 상에서 사용되고 있는 객체 생성 패턴의 예이다. 하지만 이와 같은 생성 패턴은 JS Prototype 순환 참조로 인해 포함되지 않아야 할 메서드($.init(name))가 포함되는 문제가 존재한다.

var $ = (function(){


    var $ = function(name){

        return new $.fn.init(name);
    }


    $.fn = $.prototype = {

        init: function(name){
            
            name = name || '';

            this.name = name;

            return this;
        },
        getName: function(){
            return this.name;
        }

    }

    $.fn.init.prototype = $.prototype;

    return $;

}());


console.log('A: ' + $('mohwa').init); // init function
console.log('A: ' + $('mohwa').getName()); // mohwa

2. 수정된 객체 생성 패턴 

var $ = (function(){


    var $ = function(name){

        return new init(name);
    }


    function init(name){

        name = name || '';

        this.name = name;

        return this;
    }

    init.prototype.getName = function(){

        return this.name;
    }



    return $;

}());


console.log('B: ' + $('mohwa') === $('mohwa')); // false
console.log('B: ' + $('mohwa').init); // undefined(이전 패턴과 달리 $.init(name) 메서드가 존재하지 않는다.)
console.log('B: ' + $('mohwa').getName()); // mohwa

3. 생성자 + 싱글톤 패턴

- 위 생성자 패턴에 싱글톤 패턴을 추가 하였다.

var $ = (function(){

    // 싱글톤을 위한 인스턴스 private 변수

    var instance = null;

    var $ = function(name){

        return new init(name);
    }


    function init(name){

        name = name || '';

        this.name = name;

        // 싱글톤 패턴
        return instance = instance ? instance : this;
    }

    init.prototype.getName = function(){

        return this.name;
    }



    return $;

}());


console.log('C: ' + $('mohwa') === $('mohwa')); // true
console.log('C: ' + $('mohwa').getName());

4. 객체 생성자(Class)를 강제 시킨다.

- instanceof 연산자를 통해 객체 생성자 함수($(name))를 강제 시키는 코드를 추가시킨 패턴이다.

var $ = function(name){

    name = name || '';

    var _this;
    if (!(this instanceof $)) _this = new $(name);
    else _this = this;

    _this.name = name;

    return _this;

};

var $$ = function(){

}

console.log('D: ' + $.call(new $$(), 'mohwa').name); // fn.call(context, arguments) 메서드를 사용해 호출한다.
console.log('D: ' + new $('mohwa').name);

참고 사이트:

보수란?

http://211.228.163.31/30stair/complement/complement.php?pname=complementrms

JavaScript 보수 계산기(간간히 오류가 존재한다.)

http://www.iwiz.pe.kr/bbs/view/webdev/article_51.html

N진법의 보수1

http://cms.kut.ac.kr/user/yjjang/dig12/ch02_radix.pdf

N진법의 보수2

http://www.havetop.com/xe/index.php?mid=publecture&page=7&sort_index=readed_count&order_type=asc&document_srl=2874

아래는 @카카오에서 서비스 중인 카카오 톡 / 카카오 스토리를 활용할 수 있도록 제공하는, API에 대한 소스 및 그에 대한 결과 이미지이다.

1. 카카오 톡

- URL 링크 전달 소스:

KAKAO.Talk.link('테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!', 'http://mohwa.org', 'APP Name');

- APP 링크 전달 소스:

var metainfo = { metainfo: [{ os: "android", devicetype: "phone", installurl: "market://details?id=kr.co.mobicle.SpecialForce2&feature=nav_result#?t=W10", executeurl: "kakaoagit://testtest" }, { os: "ios", devicetype: "phone", installurl: "items://itunes.apple.com/kr/app/seupesyeolposeudipenseu/id433594154?mt=8", executeurl: "kakaoagit://testtest"}] };

KAKAO.Talk.link('테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!', 'http://mohwa.org', 'APP Name', metainfo);

2. 카카오 스토리

- 텍스트 URL 포스팅 소스:

var urlinfo = { title: "(광해) 실제 역사적 진실은?", desc: "(광해 왕이 된 남자)의 역사성 부족을 논하다.", imageurl: ["http://m1.daumcdn.net/photo-media/201209/27/ohmynews/R_430x0_20120927141307222.jpg"], type: "article" 
}

KAKAO.Story.link('http://dfl.co.kr테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!테스트 메시지!!!', 'APP Name', urlinfo);

PS: 현재 모바일웹에서는 IOS, Android(네이티브 APP)에서 지원하는 이미지 포스팅은 지원하지 않는다.

3. API 가공 소스 코드

4. 참고 사이트:

카카오톡 API 테스트 페이지:

http://mohwa.org/html/kakao/kakao.html

카카오톡 API URL:

http://www.kakao.com/link/ko/api?tab=mobile

카카오 스토리 API URL:

http://www.kakao.com/link/ko/api_story?tab=mobile

Undefined Kr 그룹 발표자료

그룹 페이지:

https://www.facebook.com/groups/html5jsstudy/?bookmark_t=group

CoffeeScript 

http://goo.gl/eDwSx