五十步百步: 1월 2013

2013년 1월 31일 목요일

커맨드 패턴(Command Pattern)

출처: Head First Design Patterns : 스토리가 있는 패턴 학습법

커맨드 패턴(Command Pattern)

커맨드 패턴을 이용하면 요구 사항을 객체로 캡슐화 할 수 있으며, 매개변수를 써서 여러 가지 다른 요구 사항을 집어 넣을 수도 있다. 또한 요청 내역을 큐에 저장하거나 로그로 기록 할 수 있으며, 작업 취소 기능도 가능 하다.

이건 알게 모르게 자주 사용하고 있는 패턴이다. 특히 요즘 언어들은 자체적으로 커맨드 패턴 방식으로 코딩 할 수 있게 function 을 제공해 주므로, 그것을 이용하면 자동적으로 커맨드 패턴 형식으로 결과물이 나온다.

2013년 1월 29일 화요일

구글 블로그에 code style 적용하기

출처: How to use prettify with blogger/blogspot?

구글 블로그에는 코드 스타일 넣는 것이 없어서 찾아 보다가 좋은 팁을 발견 했다.
원본 내용에는 여러가지 방법들이 있는데, 그 중 가장 간단한 방법이 아래 방식이다.

Go to Blogger-->Layout-->Edit HTML
Copy the following snippet and paste it immediately after "<head>" in the "Edit template" field:

<link href='http://google-code-prettify.googlecode.com/svn/trunk/src/prettify.css' rel='stylesheet' type='text/css'/> <script src='http://google-code-prettify.googlecode.com/svn/trunk/src/prettify.js' type='text/javascript'></script>

After "</head>" replace "<body>" with "<body onload='prettyPrint()'>"
Click "SAVE TEMPLATE"
Go to Blogger-->Posting-->New Post. Make sure you're editing the HTML by clicking on "Edit HTML". In the empty field try:

<pre class="prettyprint">int foo=0; NSLog(@"%i", foo); </pre>

Notice if you click "Preview" now you'll see this code in black only. Don't worry (yet).
Click "PUBLISH POST" and then "VIEW BLOG". Your code should be prettified.

이렇게 간단한 방법이....

싱글턴 패턴(Singleton Pattern)

출처: Head First Design Patterns : 스토리가 있는 패턴 학습법

싱글턴 패턴(Singleton Pattern)

싱글턴 패턴은 해당 클래스의 인스턴스가 하나만 만들어지고, 어디서든지 그 인스턴스에 접근할 수 있도록 하기 위한 패턴이다.

디자인 패턴을 모르더라도 대부분 알고 있고 유용하게 사용하고 있는 패턴이다. 책에서는 보통 사용하고 있는 싱글턴 패턴 코드에 대해서 고전적인 싱글턴 패턴이라고 말을 하면서, 멀티쓰레드에서는 제대로 작동하지 않는다고 하는데... 멀티쓰레드 되면 프로그램 구조에 대해서 다시 생각해 봐야 하므로 당연한 말이 아닌지....

아무튼 이건 Class Diagram 보다는 코드를 보는게 더 이해가 빠르다.(Class Diagram 에 박스 하나 밖에 없으므로....)

[Java]
1. Thread-unsafe

public class Singleton {
    private static Singleton uniqueInstance;

    private Singleton() {}

    public static Singleton getInstance() {
        if(uniqueInstance == null) {
            uniqueInstance = new Singleton();
        }
        return uniqueInstance;
    }
}

2. Thread-safe

public class Singleton {
    private volatile static Singleton uniqueInstance;
    
    private Singleton() {}

    public static Singletone getInstance() {
        if(uniqueInstance == null) {
            synchronized(Singleton.class) {
                if(uniqueInstance == null) {
                    uniqueInstance = new Singleton();
                }
            }
        }
    }
}

[Objective C]
1. Thread-safe

@impelement Singoleton
static Singleton* sharedInstance = nil;
+ (id)sharedInstance {
    if(sharedInstance != nil) return sharedInstance;
    
    static dispatch_once_t pred;
    dispatch_once(&pred, ^{
        sharedInstance = [[self alloc] init];
    });
    
    return sharedInstance;
}
@end

멀티쓰레드가 된다면 만들어 놓고 디버깅 하려면 무지 힘드니, Singleton 을 사용한다면 프로그램 구조 설계 할때 잘 생각해서 구현 하도록 하자. 생성 외에 내부 메소드들도 멀티쓰레드 동작이 반영 되어야 할 것이다.

추상 팩토리 패턴(Abstract Factory Pattern)

출처: Head First Design Patterns : 스토리가 있는 패턴 학습법

추상 팩토리 패턴(Abstract Factory Pattern)

추상 팩토리 패턴에서는 인터페이스를 이용하여 서로 연관된, 또는 의존하는 객체를 구상 클래스를 지정하지 않고도 생성 할수 있다.

흠...이건 좀 괜찮다.

Factory method pattern 과 엮여 있는 패턴이다. Abstract factory pattern 은 내부에서 Factory method pattern 으로 구현 되어 진다.

그런데, Factory method pattern 은 상속을 통해 factory 가 구현되는 것이고, Abstract factory pattern 은 객체 중심으로 factory 가 구현되는 중요한 차이점이 있다.

factory pattern 은 상황에 맞게 factory method 를 사용할 것인지, abstract factory 를 사용할 것인지 판단 하면 되겠다.

대부분의 경우 factory method 만으로 충분 할 듯....

팩토리 메소드 패턴(Factory Method Pattern)

출처: Head First Design Patterns : 스토리가 있는 패턴 학습법

팩토리 메소드 패턴(Factory Method Pattern)

팩토리 메소드 패턴에서는 객체를 생성하기 위한 인터페이스를 정의하는데, 어떤 클래스의 인스턴스를 만들지는 서브클래스에서 결정하게 만듭니다. 팩토리 메소드 패턴을 이용하면 클래스의 인스턴스를 만드는 일을 서브클래스에게 맡긴다.

이건 좀 실망한 디자인 패턴이다. 팩토리 형식(디자인 패턴이 아니라고 하나 뭐라나...)으로 코딩을 하는 것과 팩토리 메소드 형식으로 코딩을 하는 것을 나누어 두었는데, 실제 코딩을 하다보면 아무 생각 없이 팩토리 형식으로 만들다 보면 결국에는 팩토리 메소드 패턴이 나올수 밖에 없다.

2013년 1월 17일 목요일

xcode 에서 github 사용

이것 때문에 2시간 동안 삽질 무진장 했다. 다음 단계로 하면 된다.

github 사이트에 empty project 생성(README.md, ignore 생성하는 것을 체크 하면 안됨. 완전 empty 로 생성)
xcode 로 원하는 project 생성(local repository 사용 하는 것을 체크 해야 함)
organize 실행
organize 에서 해당 프로젝트의 repository 로 이동
github 사이트로 가서 생성한 empty project 의 주소 복사(https 복사)
해당 프로젝트 repository 의 "Remotes" 항목 선택
"Add Remote" 선택 후 5번에서 복사한 주소와 이름을 입력
xcode 종료 후 다시 실행(xcode 버그 있는듯 함. 바로 remote 로 접속하면 안됨)
xcode 실행 후, "File -> Source Control -> Push" 선택
"Choose the remote to which to push changes" 창이 뜨면서 로그인 하라는 창이 나타남(github 에서 project 를 private 로 생성했음)
github.com 의 https 를 못 믿는다고 auth 창이 뜸.
auth 버튼을 클릭하고 들어가서 믿어도 된다고 체크 해 준다.
push 가 진행 됨.

다음과 같은 이유로 삽질 했으니 주의 하자.

* xcode 와 github 의 디렉토리 관리 차이의 이유로 1번 항목에서 무조건 완전 empty 로 project 를 생성 해야 한다. 만일 empty 가 아니면 연결은 되는데 제대로 작동하지 않는다.

* github 의 project 주소는 https 가 아니라 ssh 로 해도 되는데 이런 경우 github 의 help 항목에서 알려주는 대로 ssh-key 등록 절차를 진행 해 줘야 하기 때문에 좀 귀찮다.

-----------------------------------------------------------------------------
[2013.11.18 업데이트. Xcode 5.0.2용]
젠장! 젠장! 젠장! 오랫만에 ios app 이 필요해서 개발 하려고 하니, Xcode 업데이트 되면서 source controll 하는 것이 바뀌었다.....

Xcode 업데이트 되면서 github 와 연동 하는 절차는 바뀌었지만, 좀 더 쉽게 된 거 같은 생각이 든다.

1. github 에서 repository 생성 한다.(돈 주고 쓰는 계정과 개인 계정이 따로 있어서 돈 주고 쓰는 계정에서 private 로 repository 를 생성 하였음)

2. 생성한 repository 를 내 계정으로 collaboration 건다.(만일 github 계정을 동일하게 사용한다면 collaboration 단계는 필요 없음)

3. Xcode 에서 project 생성

4. Xcode 프로젝트의 "Source Controll" 메뉴의 Configure 로 들어 가서 remote 에서 "Add Remote" 를 선택해서 github repository URL 을 추가 한다.

5. Xcode 의 Perference > Accounts 메뉴로 들어 가면, 금방 추가한 github repository 에 User Name, Password 를 추가 한다.(User Name 에서 email address 형식이 아니라 id 형식이 되어야 함)

6. 테스트. 소스 코드 수정 후, commit, push 되는지 테스트

[주의]
* 정보를 제대로 넣었는데 github 에 인증이 안된다고 할때가 있는데, mac 의 keychain 에 등록된 로그인 정보가 잘못 되어서 그럴 수 있으니, 이럴때는 github 관련 keychain 을 모두 삭제 하고 다시 로그인 시도 하면 된다(github 계정이 여러개 라서 이런 경우가 발생 했음)

* repository login 설정에서 User Name 을 email 형식으로 적었는데, 로그인이 안되서 id 형식으로 사용 했음. 이건 제대로 테스트 안 한 것인데, keychain 과 엮여서 그럴 수도 있음. 현재는 잘 되니....email 형태는 테스트 하지 않음.

2013년 1월 7일 월요일

데코레이터 패턴(Decorator Pattern)

출처: Head First Design Patterns : 스토리가 있는 패턴 학습법

데코레이터 패턴(Decorator Pattern)

객체에 추가적인 요건을 동적으로 첨가한다. 데코레이터는 서브클래스를 만드는 것을 통해서 기능을 유연하게 확장할 수 있는 방법을 제공한다.

데코레이터 라니 정말 잘 지은 이름이 아닌가, 솔직히 데코레이터 패턴은 내용 보다는 이름에 감탄을 한 디자인 패턴이다.

Head First Design Patterns 의 예제가 정말 상황에 맞게 잘되어 있어서 Class Diagram 을 몇 부분 수정하여 사용하고 있다. 데코레이터 패턴과 별다방 커피 종류라니 정말 딱 맞는 예시 이다.

데코레이턴 패턴은 실제로 java.io 에서 처음 접해 본 것인데, 진짜 처음 보면 클래스 갯수에서 막막함을 느끼기도 할만한 패턴 일듯도 하다.

2013년 1월 6일 일요일

모던 아랑전

모던 아랑전

모던 팥쥐전의 시리즈로 나온 전래 동화 재해석 공포 소설이다.

모던 팥쥐전과 마찬가지로 기묘한 느낌을 받을 수 있는데, 1년 후에 나온 소설이라서 그런지 이전 보다 조금 더 나은 느낌이 들었다.

이런 종류의 소설을 좋아하는 사람에게는 추천한다.

모던 팥쥐전

모던 팥쥐전

KBS 라디오 독서실을 통해서 알게된 조선희 작가의 소설이다.

전래 동화를 재해석하여 무서운 것이 아니라 기묘한 느낌을 받도록 공포 코드를 잘 버무려서 읽고 있는 내내 묘한 느낌을 받았다. 물론 이미 감수성이 무던해져 버려서 책을 덮고 나서는 그냥 지나간 이야기가 되어 버리지만....ㅜㅜ

기묘한 이야기를 좋아한다면 추천해 줄 만하다.
후편인 모던 아랑전 도 있다.

옵저버 패턴(Observer Pattern)

출처: Head First Design Patterns : 스토리가 있는 패턴 학습법

옵저버 패턴(Observer Pattern)

한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다(one-to-many) 의존성을 정의 한다.

subject 가 observer 에서 push 로 정보를 내리는 것과 observer 가 subject 에서 정보를 pool 할 수 있도록 하였다. pool 이 있으면 기능적으로 좋을듯 한데, 이렇게 되니 뭔가 꼬이는 느낌이 든다.

스타크래프트 observer 때문에, subject 와 observer 의 역할을 반대로 생각하는 함정이 있을수도 있을듯 하다.

참고로 패키지로 묶은 것은 ArgoUML 을 제대로 사용하지 못하여 Class Diagram 그룹핑을 어떻게 시킬줄 몰라서 묶은거라는....ㅜㅜ

2013년 1월 4일 금요일

스트래티지 패턴(strategy pattern)

출처: Head First Design Patterns : 스토리가 있는 패턴 학습법

스트래티지 패턴(Strategy Pattern)

알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다. 스트래티지 패턴을 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경 할 수 있다.

클래스 다이어그램에서 보듯이 MallardDuck, RedheadDuck, RubberDuck, DecoyDuck 에 대해서 fly, quack 하는 행동이 다르다.

때문에 공통 부분은 Duck 에서 구현을 하고, 다른 부분은 interface-class 로 그룹화 시킨 또 다른 알고리즘 군에서 구현하고 있다.

개발자가 사용하는 MallardDuck, ..., DecoyDuck 에서는 각각에 따른 display 를 override 시키고, setFlyBehavior, setQuackBehavior 를 통해서 부모 클래스(Duck)의 flyBehavior, quackBehavior 를 설정 한다.

결국 어느 Duck 에서 fly, quack 을 하더라도 상황에 맞게 동작하게 된다.

학교 다닐때 소프트웨어 공학을 수강하면서 공부한 디자인 패턴을 요즘 다시 보고 있다.
기억이 새록새록 하다.

요즘은 교제도 좋아서 재미있게 웃어 가며 마치 소설책 보듯이 봐도 이해가 쉽게 되니, 참 좋은 세상이다. 학생때는 정말 이해 되지 않았었는데...사실 그때야 프로그램을 제대로 만들지 않았으니 필요성도 못 느꼈고, 필요성을 못 느끼니 머리에 제대로 떠오르지 않아 무조건 외운 기억 밖에 없다.

UML 부터 프로그램을 시작하면 설계가 구조화 되고 좋긴한데, 이것 부터 잡고 있으면 프로그램 안하고 그림 그리기 놀이 하고 있다는 말들이 많아서...에휴....

화씨 온도(Fahrenheit)를 사용하는 이유가 뭘까?

화씨에서 섭씨로 바꾸는 예제 코드를 보던 중 갑자기 화씨 온도가 있는 이유가 궁금하여 위키를 뒤져 보았다.

화씨 온도

화씨 온도(華氏, Fahrenheit)는 독일의 다니엘 가브리엘 파렌하이트(Daniel Gabriel Fahrenheit)의 이름을 딴 온도 단위이며, 기호로는 ℉를 쓴다. 물이 어는 온도는 32도(섭씨 0도)이며, 물이 끓는 온도는 212도(섭씨 100도)이므로, 이 사이의 온도는 180등분된다. 과거에는 영국과 미국의 영향으로 영어권의 여러 나라에서 널리 쓰였고, 이 때문에 “English Unit”이라고 표현하기도 한다. 그러나 현재 영국, 캐나다 등 대부분의 영어권 국가에서도 미터법을 채택하면서 섭씨로 바꾸었고, 미국을 비롯한 극소수의 국가에서만 여전히 공식적인 단위로 사용하고 있다. 화씨(華氏)란 이름은 독일인명인 파렌하이트(Fahrenheit)의 중국 음역어 ‘화륜해(華倫海)’에서 유래한다.

화씨 100℉는 섭씨 37.8℃로 인간의 체온과 비슷하다.

섭씨 온도

섭씨 온도(Celsius , 攝氏溫度)는 1 atm에서의 물의 어는점을 0도, 끓는점을 100도로 정한 온도 체계이며, 기호는 ℃이다. 1742년 스웨덴의 천문학자 안데르스 셀시우스가 처음으로 제안하였으며, 영어 등에서는 제안자의 이름을 따 ‘셀시어스’로 부르고 있다. 셀시우스는 물의 어는점을 100도, 끓는점을 0도로 제안하였으나 사용이 불편하여 후에 끓는 점과 어는 점의 기준을 바꾸었다. 하지만 온도 단위가 같은 100등분을 하였으므로 셀시우스의 이름을 따서 섭씨 온도라고 부른다. ‘섭씨(攝氏)’라는 이름은 셀시우스의 중국 음역어 ‘섭이사(攝爾思)’에서 유래한다.

화씨 온도, 섭씨 온도는 아마 고등학교때 배운 것으로 기억하는데, 당시 뭔지 정의 및 변환만 알았지, 온도 관련 단위기 두개가 존재하는 이유에 대해서는 들은 기억이 없다.

위키를 더 뒤져 보니 화씨 온도는 1714년 다니엘 가브리엘 파렌하이트 가 온도계의 화씨 눈금을 생각했다고 하며, 섭씨 온도는 안드레스 셀시우스가 1724년에 제한 한 것으로 나온다.

결국 화씨 온도가 섭씨 온도 보다 먼저 나와 기존에 사용하던 온도 도량형 보다 더 편하기 때문에 그 당시 기준으로 사용하는 것이 아직까지 그대로 사용 중인 것으로 보인다.

오늘날 까지 화씨 온도가 살아 있는 것으로 보아 섭씨 온도에 비해서 나쁘지 않은 것으로 생각되며(섭씨 온도에 적응이 된 사람은 나쁘게 보이겠지만) 기준 도량형 변경이란 것이 문화, 관습, 자존심, 깊게 들어가면 이익집단 까지 연관 될 수 있는 힘든 일이기 때문에 아직까지 사용하고 있는 듯 하다.

참고로 화씨 온도에서 섭씨 온도로 변경하는 공식은

섭씨온도 = (화씨온도 * 32.0) * 5.0 * 9.0

이다.

2013년 1월 3일 목요일

자바스크립트 완벽 가이드

자바스크립트 완벽 가이드

따로 설명이 필요 없는 책이라 할 정도로 자바스크립트 공부하려면 필수적인 책이라고 본다.
자바스크립트에 대해서 copy & paste 만 할 때, 자바스크립트 공부를 위해서 가장 처음 본 책이다.

실력이 없어서 그런지 몰라도 책을 볼 당시 예제 코드가 거진 예술이라고 감탄을 하고 봤었다.

책이 좀 두껍고 그림이 많이 없다는게 단점이라고 할 수 있지만, 내용이 이 모든 것을 커버 할 정도로 충실 하다.

적극 추천!!

2013년 1월 2일 수요일

jQuery 1.7 작고 강력한 자바스크립트 라이브러리

jQuery 1.7 작고 강력한 자바스크립트 라이브러리

원래는 다른 책을 사려고 했으나, 영풍문고에 사려고하는 책이 없어서 이것 저것 뒤적이다가 괜찮은듯 보여서 구매 했었다.

그런데, jQuery 하나도 모르는 상태에서 봐서 그런지 모르겠지만, 책값 이상의 값어치를 뽑았다. 요것을 바탕으로 나름 괜찮은 웹앱을 하나 만들었으니 말이다...

그런데, 조인이라는 무서운 놈의 등장으로 개발한 웹앱은 아마 묻히지 않을까 싶기도 하다.
에휴...

The iOS5 Developer's Cookbook (Third Edition)

The iOS 5 Developer's Cookbook

한동안 jQuery 만 가지고 놀다가 iOS 용 javascript canvas 가속기 테스트/개발이 필요하다고 하여 구입한 책이다.

이전에 objective-c 만 공부한 이후, Apple 개발자 사이트의 문서만 보고 iOS용 WRT 개발을 했었기 때문에, 책으로 된 iOS 개발 교제가 필요 했었다.

인터넷으로 검색 결과 평이 괜찮아서 구입 했는데 무진장 두껍다.(무려 1053 페이지)

현재 2장 보고 있는데, iOS 의 ARC 메모리 관리와 MRR 메모리 관리에 대해서 비교하여 설명 해 둔 것만으로도 책 가격은 뽑은듯 싶다(사실 시간 없다는 핑계로 찾아 보지 않고 대충 개요만 잡고 있었던 상태 였었다.)

현재까지는 만족한다.

혹시 iOS 개발에 대해서 아무것도 모르는 상태에서 이 책으로 공부하는 것은 권하지 않는다.
아마 책의 분량이 많아서 진도 뽑기가 힘들지 않을까 싶다.

최소한 objective-c 관련 책 한권 정도는 보고 난 다음, 이 책으로 공부하는 것을 권한다.