아이큐2000으로 열심히 게임하는 동안 몇년이 흘렀고 잡지에서 또다시 잡스를 만날 수 있었다. 잡스는 애플에서 쫓겨났고 다시 회사를 만들었다. 그리고 그곳에서 넥스트(NeXT)라는 컴퓨터를 만들었는데 검정색의 세련된 컴퓨터는 상상을 초월하는 가격이었다. 당시 나에게 넥스트 컴퓨터는 건담과 같이 비현실적인 존재였다.

그로부터 몇년 후 나는 다시 엄마를 졸라 XT를 장만했다. 아이큐2000과 달리 이 XT는 부팅하면 DOS 콘솔 화면이 떴다. 명령어를 하나하나 입력하다 보면 뭔가 전문가가 된 듯한 느낌이 들었다. 하지만 하는 거라고는 게임과 베이직으로 짠 가계부가 전부였다. 그래도 허큘래스 그래픽과 8비트 애드립 사운드를 들으면서 즐겼던 폴리스 퀘스트와 인디아나 존스는 정말 재미있었다.

나름 XT에 만족하면서 살고 있었는데 친구 봄길이네 집에 놀러가서 다시 한번 더 충격을 받았다. 봄길네 방엔 일반인이 흔히 접할 수 없는 매킨토시라는 놈이 있었다. 컬러 모니터에서 연출되는 화려한 윈도우 UI 그리고 게임들! 잡스가 만든 컴퓨터를 오랫동안 만져보는 건 처음이었다. 놀라운 경험이었다. 봄길이가 엄청 부러웠다. 이런 멋진 컴퓨터를 가지고 있다니!

어느덧 고등학생이 되었다. 잠깐잠깐 게임을 즐기긴 했지만 입시 때문에 컴퓨터는 점점 멀어져 갔다. 잡스란 존재도 자연스럽게 잊혀졌다. 그리고 무사히 컴퓨터 공학과에 입학했고 공돌이가 되었다. 용산에 가서 부품을 사고 집에서 열심히 조립한 후 DOS와 윈도우즈 3.0을 깔았다. 그리고 몇달 후 윈도우즈 95를 접했다. 윈도우즈 3.0과는 차원이 달랐다. 나는 마이크로소프트에 열광했고 빌게이츠는 나의 영웅이었다.

성적이 좋지 않았지만 졸업을 하고 엔씨소프트에 입사했다. 당시 엔씨소프트는 MS 친화적인 기업이었다. 회사의 모든 컴퓨터에는 윈도우즈 XP가 깔려있었다. 소문에 의하면 다른 회사의 디자이너들은 작업할 때 맥을 쓴다고 들었지만 직접 눈으로 확인하진 못했다 ㅎ.

6년 후 나는 엔씨를 나와서 델리마운트라는 회사를 만들었다. 많은 일들이 있었다. 2번의 실패 후 회사를 유지하기 위해서 용역 개발을 시작했다. 그리고 엄청난 갑을 만났다. 6개월짜리 프로젝트는 1년 2개월 넘게 진행되었고 잔금도 받지 못한 체 소송에 휘말렸다. 함께한 동료들은 각자 살 길을 찾아 떠났고 나는 혼자 남게 되었다. 미친 듯이 책을 읽었다. 그렇게 몇달이 흐르던 중 아이폰이 한국에 출시되었다. 경제적으로 힘든 상황이라 잠시 망설였지만 할부라는 달콤함 빠져 결국 아이폰을 지르고 말았다. 그리고 새로운 세계를 만났다.

때마침 절스군이 돌아왔고 나는 다시 꿈을 꾸었다. 이대로 끝낼 수는 없었기에 아이폰에 실낱같은 희망을 걸었다. 이 모든 것이 잡스가 나에게 준 선물처럼 느껴졌다. 경제적으로 어려운 상황이었기에 또다시 엄마의 도움으로 2008년형 아이맥 24인치 모델을 리퍼비시로 장만하게 된다. 아이맥은 간지 그 자체였고 옆에 있는 PC들은 볼품없이 느껴졌다. 처음엔 생소한 OS X의 UI에 불편했지만 조금씩 익숙해져 갔다. 그리고 어느 순간부터 구석구석 묻어있는 잡스의 디테일이 느껴졌다. 아… 잡스는 이런 사람이구나.

Objective-C와 XCode는 생소했지만 재미있었다. 한 자동차 수입 업체의 앱을 개발하면서 실전 경험을 쌓았다. 그리고 4월부터 리피 개발을 시작했고 같은 해 8월에 앱스토어 등록 신청을 했다. 리피는 실험적인 프로젝트였다. 몇년 만에 다시 시작하는 서비스 개발은 많은 용기와 경험이 필요했다. 새로운 기술과 트렌드를 적용하고 피드백을 받으면서 서비스 개발과 운영에 조금씩 익숙해져 갔다. 그러는 동안 미남1호와 곰썬이 합류했고 2011년 10월 커플로그라는 두번째 서비스의 오픈을 앞두고 있다. 그리고 앞으로 더 많은 사람들이 함께할 것이다.

개인적으로 잡스가 특별한 이유는 그 사람의 스타일 때문이다. 잡스는 매우 예민하고 자유로운 사람이다. 몇해 전만 해도 이런 성격은 CEO로 부적합하다고 했다. 하지만 잡스는 성공했고 지금 애플은 최고다. 그리고 애플이 지금의 위치까지 올라갈 수 있었던 건 잡스가 있었기 때문이다. (물론 잡스 혼자만의 노력은 아니다) 비록 내가 있는 곳이 캘리포니아는 아니지만 잡스는 나의 영웅이자 롤모델이다. 그리고 언제가 잡스의 빈자리를 채울 수 있는 사람이 되기를 오늘도 꿈꾼다.

리피는 채널(channel) 중심의 소셜 서비스(SNS)입니다. 기존의 트위터나 미투데이와 같은 소셜 서비스들이 개인 중심이라면 리피는 채널 중심입니다. 현재 리피는 아이폰 앱으로 먼저 출시되었으며 빠른 시일 내에 웹 및 모바일 웹 버전을 출시할 예정입니다.

요즘은 많은 분들이 트위터나 미투데이를 사용하지만 아직까지 트위터나 미투데이를 어려워 하시는 분들도 있습니다. 트위터나 미투데이의 가장 큰 단점은 처음 가입했을 때 별로 할 일이 없다는 점입니다. 구독자(follower)나 친구가 없으니 당연히 혼자 놀기를 할 수밖에 없습니다. 많은 경우 혼자 놀다 흥미를 잃어버리곤 합니다. 그러나 소셜시대라는 대세를 거스를 수 없다면 팔로우(follow) 또는 친구 신청 열심히 해야 합니다. 모든 일은 비용이 들기 마련이지만 당장 누군가와 대화하고 싶은데 그럴 수 없다는 것은 매우 안타까운 상황입니다. 바로 이 점이 처음 리피를 기획하게 된 이유였습니다.

처음 만나는 사람들이 쉽게 친해질 수 있는 방법은 공통의 관심사를 찾는 것입니다. 우리는 흔히 모르는 사람(이성이든 동성이든)을 처음 만난 경우 이것저것 내용을 바꿔어 가면서 대화를 하다가 공통으로 좋아하는 주제가 나오면 해당 이야기를 이어가면서 서로 동질감을 느끼고 호감으로 발전해갑니다. 이런 패턴을 관찰하면서 채널을 이란 개념을 만들었습니다. 채널이란 특정 주제에 대해서 대화할 수 있는 공간으로 채팅의 채팅방에서 그 모티브를 가져왔습니다. 리피 안에 다양한 주제의 채널이 열려있고 누구든지 그리고 언제든지 관심이 가는 채널만 찾아 들어가면 공통의 관심사를 가진 사람과 바로 대화할 수 있을 것이라고 생각했습니다.

채팅은 실시간 대화인 반면에 트위터나 미투데이와 같은 소셜 서비스는 실시간이라고 보기는 어렵습니다. 물론 블로그와 같은 서비스와 비교해서 실시간 성이 강하며 스마트 폰의 앱들은 알림(push) 기능을 지원하기 때문에 거의 실시간에 가깝다고 볼 수 있습니다. 실시간 성이란 결국 속도감을 의미하며 속도감은 트위터와 같은 단문 대화 서비스의 핵심적인 요소입니다. 그럼에도 불구하고 트위터나 미투데이는 정확한 의미에서 실시간 서비스가 아닙니다. 그리고 실시간이라고 무조건 좋은 것은 아닙니다. 실시간이라는 것은 많은 집중을 요구하기 때문에 그만큼 사용 부담이 크다는 것을 의미하기도 합니다. 사용 부담이 크다는 것은 결과적으로 사용 빈도가 떨어뜨리는 요인이 됩니다.

아무튼 채팅의 채널이라는 개념을 소셜 서비스에 맞게 바꿀 필요가 있었습니다. 우선 채팅의 입장(join)이라는 개념을 빼버렸습니다. 채널이라는 것이 앱 또는 웹 상에 완전히 열려 있기 때문에 폐쇄적이고 번거로운 입장이라는 개념은 필요하지 않았습니다. 대신 구독(follow) 개념을 추가해서 관심 있는 채널의 대화 내용을 모아볼 수 있도록 기획하였습니다. 마찬가지로 채널이 열려 있기 때문에 누구든지 대화를 올릴 수 있도록 했습니다. 극단적인 경우 대화를 올리지만 구독은 하지 않는 경우도 허용하였습니다.

그리고 채널에 유효 시간이라는 개념을 추가하였습니다. 채팅의 채널은 마지작 참여자가 퇴장(quit)하는 순간 채널이 종료됩니다. 하지만 리피에는 입장이라는 개념이 없기 때문에 퇴장이라는 개념 또한 없으며 결국 채널은 계속 지속될 수 밖에 없습니다. 채널이 계속 지속되는 경우 실시간 성이 떨어지고 결국 속도감도 떨어질 수 밖에 없다고 판단하였습니다. 그래서 채널을 만든 시점부터 24시간 동안만 대화를 올릴 수 있도록 기획했습니다. 24시간이 지나면 더이상 대화를 올릴 수 없기 때문에 최신 대화 순으로 보여지는 타임라인 상에서 해당 채널의 대화는 더이상 노출되지 않게 됩니다. 물론 채널은 열려있기 때문에 언제든지 이전 채널을 찾아들어갈 수 있습니다.

지금까지 채널의 제작 의도에 대해서 정리해보았습니다. 개발하면서 이것거것 고민을 많이 했기 때문에 할 말은 많지만 글이 길어지면 적는 사람도 읽는 사람도 힘들어지기 때문에 이쯤에서 마무리하려 합니다. 아직 못다한 얘기는 다른 주제로 다시 포스팅하도록 하겠습니다.

이 글을 읽는 동안 리피에 대해서 관심이 생기셨다면 꼭! 리피를 써보시기 바랍니다. 리피는 아이폰 앱스토어에서 다운받으실 수 있습니다. 만약 아이폰이 없으시다면 조금만 기다려 주시기 바랍니다. 가능한 빨리 웹 및 모바일 웹 버전을 출시하도록 하겠습니다.

더불어 리피 아이폰 앱 등록 기념 이벤트가 진행중입니다. 많은 참여 부탁드립니다~

흔히들 프로그래머들이 소통 능력이 떨어진다고 한다. 기획자나 디자이너는 작업 흐름 상 자신의 작업이 끝나면 다른 사람에게 자신의 작업물을 넘겨주고 자신의 작업물이 최종 결과물에 잘 반영될 수 있도록 뒷 사람에게 소통을 시도한다. 그러나 프로그래머는 최종 결과물을 만드는 사람들이다(물론 그 뒤에 QA가 있기는 하지만 QA는 결과물을 확인할 뿐이지 제품을 만들지는 않는다). 그래서 프로그래머들은 상대적으로 소통의 필요성을 덜 느끼며 결국 다른 작업자들 보다 소통 능력이 떨어진다.

그러나 모든 프로그래머들의 소통 능력이 떨어지는 것은 아니다. 익스트림 프로그래밍(XP)에서는 프로그래머의 소통 능력을 매우 중요하게 생각한다. 고객과 개발자 간의 소통 능력 뿐만 아니라 프로그래머 간의 소통 능력에 대해서도 매우 중요하게 다루고 있다. 우리 회사에서도 짝-프로그래밍(pair programming)을 하기 때문에 프로그래머의 소통 능력을 매우 중요하게 생각한다. 나아가 짝-프로그래밍을 통해서 프로그래머들의 소통 능력이 많이 향상되고 있다.

대부분의 프로젝트라는 것이 여러 사람의 공동 작업이고 공동 작업에서 가장 중요한 것은 소통이다. 프로젝트 팀 구성원들 간에 얼마나 소통이 원활하냐에 따라 프로젝트 진행 및 결과가 결정된다.

소통을 잘 하는 방법은 간단하다. 잘 듣고 잘 말하면 된다. 우선 상대방이 전달하려는 내용을 잘 들어야 한다. 상대방의 생각을 충분히 이해한 다음 정리된 자신의 생각을 상대방에서 말하면 된다. 우리 팀은 이것을 야구의 캐치볼에 비유하곤 한다. 캐치볼은 2명(일반적으로)이 플레이어가 하나의 공을 주고 받는 행동이다. 공이 하나이기 때문에 내가 공을 받아야 상대방에게 공을 던질 수 있다. 대화도 마찬가지이다. 내가 나의 생각을 말하기 위해서는 상대방의 생각을 들어야 한다.

그리고 공을 던질 때엔 상대방의 가슴을 향해서 던진다. 상대방이 다음 동작을 잘 이어갈 수 있도록 하기 위한 배려이다. 대화도 마찬가지이다. 내가 하고 싶은 말을 아무렇게나 하는 것이 아니라 상대방이 잘 알아들을 수 있도록 최대한 배려해서 말해야 한다. 그러기 위해서 말하기 전에 듣는 사람의 입장을 생각해봐야 한다.

끝으로 상대방이 던진 공이 내 가슴을 향해 날아오지 않으면 내가 움직여야 한다. 상대방이 가슴을 향해서 던지려 해도 사람이기 때문에 원하는 곳을 공이 날아오지 못할 때가 많다. 특히 초보자의 경우엔 더욱 그러하다. 그래서 공을 받는 사람이 움직여야 한다. 만약 움직이지 않으면 캐치볼은 중단된다. 대화도 비슷한다. 상대방의 하는 말이 자신이 것이 아닐 때 감정 상하지 않고 상대방의 생각을 이해하려고 노력해야 한다. 그리고 대화를 계속 이어나아가야 한다.

요즘은 프로그래머들이 블로그나 트위터, 미투데이에서 많은 대화를 시도하고 있다. 하지만 아직까지 내가 경험한 프로그래머 중에는 소통 능력이 떨어지는 사람들이 많다. 인간은 혼자 살 수 없듯이 프로젝트도 혼자할 수 없다.

프로그래머들이여, 오늘부터 캐치볼을 해라!

1
2
3

UITableViewCell* cell;
// ...
[ cell setText: @"Hello" ];

3.0부터는 textLabel 메소드로부터 반환 받은 UILabel 객체에 텍스트를 설정하도록 변경되었습니다.

1
2
3
4

UITableViewCell* cell;
// ...
UILabel* label = [ cell textLabel ];
[ label setText: @"Hello" ];

이 경우 버전 2.1에서는 컴파일 오류가 발생합니다. 하지만 국내에 출시된 아이폰의 경우 3.1부터 시작하기 때문에 하위 호환 문제는 크게 신경쓰지 않아도 될 듯 합니다.

NSXMLParser는 XML 문서를 순차적으로 분석(parse)하면서 이벤트별 처리를 위임(delegate)하는 방식입니다. 따라서 NSXMLDocument를 사용하는 예제보다는 훨씬 더 복잡합니다. 참고로 iPhone에서 사용할 수 있는 XML 관련 라이브러리들이 개발되어 있기 때문에 해당 라이브러리를 익혀서 사용하는 것이 개발 효율은 더 좋을 것 같습니다. 하지만 NSXMLParser를 이용해서 구현하면 메모리도 적게 먹고 나름 성능 향상을 기대할 수 기대할 수 있기 때문에 직접 작성하는 것도 알아두면 좋을 듯 합니다.

예제에 포함된 파일 목록은 아래와 같습니다.

우선 showrooms.xml은 아래와 같습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<?xml version="1.0" encoding="UTF-8" ?>
 
<showrooms>
  <showroom>
    <name>강남전시장</name>
    <phone>02-111-1111</phone>
    <dealer>
      <name>김태연</name>
    </dealer>
  </showroom>
  <showroom>
    <name>삼성전시장</name>
    <phone>02-222-2222</phone>
    <dealer>
      <name>구하라</name>
    </dealer>
  </showroom>
</showrooms>

예제에서 showroom 및 dealer 엘리먼트가 각각 name 엘리먼트를 자식으로 가지도록 작성했습니다.

Dealer.h와 Dealer.m은 다음과 같습니다.

1
2
3
4
5
6
7
8
9

#import <Foundation/Foundation.h>
 
 
@interface Dealer : NSObject
{
  NSString* _name;
}
  @property( copy ) NSString* name;
@end

1
2
3
4
5
6

#import "Dealer.h"
 
 
@implementation Dealer
  @synthesize name = _name;
@end

Showroom.h와 Showroom.m은 다음과 같습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13

#import "Dealer.h"
 
 
@interface Showroom : NSObject
{
  NSString* _name;
  NSString* _phone;
  Dealer* _dealer;
}
  @property( copy ) NSString* name;
  @property( copy ) NSString* phone;
  @property( retain ) Dealer* dealer;
@end

1
2
3
4
5
6
7
8

#import "Showroom.h"
 
 
@implementation Showroom
  @synthesize name = _name;
  @synthesize phone = _phone;
  @synthesize dealer = _dealer;
@end

NSXMLParser는 NSXMLDocument의 NSXMLNode처럼 모델이 없기 때문에 분석(parse) 결과를 담을 수 있는 모델이 필요합니다. 이 모델 클래스들은 MVC에도 적용될 수 있기 때문에 모델 클래스를 만들어 두면 조금 더 우아한 프로그래밍할 수 있습니다. 모델 클래스들은 간단하기 때문에 자세한 설명은 생략하도록 하겠습니다.

ShowroomsXmlParser.h는 아래와 같습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#import "Showroom.h"
 
 
@interface ShowroomsXmlParser : NSObject
{
  NSMutableArray* _showrooms;
  NSMutableArray* _elementStack;
}
  - (void) parser: (NSXMLParser*) parser 
      didStartElement: (NSString*) elementName 
      namespaceURI: (NSString*) namespaceURI 
      qualifiedName: (NSString*) qualifiedName 
      attributes: (NSDictionary*) attributeDict;
  - (void) parser: (NSXMLParser*) parser
      foundCharacters: (NSString*) string;
  - (void) parser: (NSXMLParser*) parser 
      didEndElement: (NSString*) elementName
      namespaceURI: (NSString*) namespaceURI 
      qualifiedName: (NSString*) qName;
  - (NSMutableArray*) parseContentOfUrl: (NSURL*) url;
@end

ShowroomsXmlParser는 NSXMLParser가 발생시키는 event를 처리해서 Showroom 객체 배열을 넘겨주는 클래스입니다. NSXMLParser가 위임(delegate)하는 method들을 처리하기 위해서 NSXMLParserDelegate 프로토콜을 구현해야 합니다. 참고로 프로토콜은 자바에서 interface랑 동일합니다. 멤버 변수 _elementStack은 파서의 트리 탐색 경로 및 정보를 담아두는 스택입니다.

ShowroomsXmlParse.m은 아래와 같습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110

#import "ShowroomsXmlParser.h"
 
 
NSString* const SHOWROOM = @"showroom";
NSString* const DEALER = @"dealer";
NSString* const NAME = @"name";
NSString* const PHONE = @"phone";
 
 
@implementation ShowroomsXmlParser
  - (void) parser: (NSXMLParser*) parser 
      didStartElement: (NSString*) elementName 
      namespaceURI: (NSString*) namespaceURI 
      qualifiedName: (NSString*) qualifiedName 
      attributes: (NSDictionary*) attributeDict
  {
    if ( TRUE == [ elementName isEqualToString: SHOWROOM ] )
    {
      Showroom* showroom = [ Showroom new ];
      [ _elementStack addObject: showroom ];
    }
    else if ( TRUE == [ elementName isEqualToString: DEALER ] )
    {
      Dealer* dealer = [ Dealer new ];
      Showroom* showroom = (Showroom*)[ _elementStack lastObject ];
      [ showroom setDealer: dealer ];
 
      [ _elementStack addObject: dealer ];
    }
    else if ( TRUE == [ elementName isEqualToString: NAME ] ||
      TRUE == [ elementName isEqualToString: PHONE ] )
    {
      NSString* element = [ NSString stringWithString: elementName ];
      [ _elementStack addObject: element ];
    }
  }
 
  - (void) parser: (NSXMLParser*) parser
      foundCharacters: (NSString*) string
  {
    NSCharacterSet* characterSet = [ NSCharacterSet 
      whitespaceAndNewlineCharacterSet ];
    NSString* trimmedValue = [ string stringByTrimmingCharactersInSet:
      characterSet ];
    if ( 0 == [ trimmedValue length ] )
    {
      return;
    }
 
    id element = [ _elementStack lastObject ];
    if ( TRUE == [ element isKindOfClass: [ NSString class ] ] )
    {
      NSUInteger count = [ _elementStack count ];
      NSUInteger index = count - 2;
      id parentElement = [ _elementStack objectAtIndex: index ];
 
      if ( TRUE == [ element isEqualToString: PHONE ] )
      {
        Showroom* showroom = (Showroom*)parentElement;
        [ showroom setPhone: trimmedValue ];
      }
      else if ( TRUE == [ element isEqualToString: NAME ] )
      {
        if ( TRUE == [ parentElement isMemberOfClass: [ Showroom class ] ] )
        {
          Showroom* showroom = (Showroom*)parentElement;
          [ showroom setName: trimmedValue ];
        }
        else if ( TRUE == [ parentElement isMemberOfClass: [ Dealer class ] ] )
        {
          Dealer* dealer = (Dealer*)parentElement;
          [ dealer setName: trimmedValue ];
        }
      }
    }
  }
 
  - (void) parser: (NSXMLParser*) parser 
      didEndElement: (NSString*) elementName
      namespaceURI: (NSString*) namespaceURI 
      qualifiedName: (NSString*) qName
  {
    if ( TRUE == [ elementName isEqualToString: SHOWROOM ] )
    {
      Showroom* showroom = (Showroom*)[ _elementStack lastObject ];
      [ _showrooms addObject: showroom ];
      [ _elementStack removeLastObject ];
    }
    else if ( TRUE == [ elementName isEqualToString: DEALER ] ||
      TRUE == [ elementName isEqualToString: NAME ] ||
      TRUE == [ elementName isEqualToString: PHONE ] )
    {
      [ _elementStack removeLastObject ];
    }
  }
 
  - (NSMutableArray*) parseContentOfUrl: (NSURL*) url
  {
    NSXMLParser* xmlParser = [ [ NSXMLParser alloc ] 
      initWithContentsOfURL: url ];
    [ xmlParser setDelegate: self ];
 
    _showrooms = [ NSMutableArray arrayWithCapacity: 1024 ];
    _elementStack = [ NSMutableArray arrayWithCapacity: 1024 ];
 
    [ xmlParser parse ];
 
    return _showrooms;
  }
@end

NSXMLParser가 동작하기 위해서는 최소한 아래의 메소드들이 구현되어야 합니다.

• parser:didStartElement:namespaceURI:qualifiedName:attributes: (이하 didStart)
• parser:foundCharacters: (이하 found)
• parser:didEndElement:namespaceURI:qualifiedName: (이하 didEnd)

didStart는 파서가 엘리먼트의 시작 태그를 만났을 때 호출됩니다. 비단말(nonterminal) 노드인 경우 엘리먼트 해당하는 모델 객체를 생성한 후 스택에 넣습니다. 단말(terminal) 노드인 경우 엘리먼트 이름으로 NSString 객체를 만들 후 스택에 넣습니다.

found는 파서가 엘리먼트를 제외한 스트링을 만날을 때 호출됩니다. 인자로 넘어온 스트링의 앞뒤 공백을 제거합니다. 유효한 스트링(이하 속성값)인 경우 스택에서 마지막으로 추가된 NSString 객체를 제거합니다. 제거된 NSString 객체의 값에 따라 적절한 부모 모델 객체의 속성(property)을 속성값으로 설정합니다. 만약 엘리먼트 이름이 NAME인 경우 중복되기 때문에 부모 모델 객체 클래스에 확인합니다.

didEnd는 파서가 엘리먼트의 종료 태그를 만났을 때 호출됩니다. 스택에서 모델 객체를 제거하고 SHOWROOM인 경우 _showrooms 배열 객체에 해당 객체를 추가합니다.

끝으로 콘솔 화면에서 결과를 확인할 수 있는 showrooms_xml_parser.m 파일은 아래와 같습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

#import "ShowroomsXmlParser.h"
 
 
int main( int argc, char* argv[] )
{
  NSAutoreleasePool* pool = [ NSAutoreleasePool new ];
 
  ShowroomsXmlParser* xmlParser = [ ShowroomsXmlParser new ];
  NSURL* url = [ NSURL URLWithString: 
    @"http://www.yourserver.com/showrooms.xml" ];
  NSMutableArray* showrooms = [ xmlParser parseContentOfUrl: url ];
 
  for ( Showroom* showroom in showrooms )
  {
    Dealer* dealer = [ showroom dealer ];
    NSLog( @"%@ %@ (%@)", [ showroom name ], [ showroom phone ], 
      [ dealer name ] );
  }
 
  [ xmlParser release ];
  [ url release ];
 
  [ pool drain ];
  return 0;
}

해당 소스들을 컴파일 하기 위해서는 아래의 명령어를 실행합니다.

1
2

$ gcc -framework Foundation Dealer.m Showroom.m ShowroomsXmlParser.m showrooms_xml_parser.m
-o showrooms_xml_parser

실행 결과 화면은 아래와 같습니다.

1
2
3

$ ./showrooms_xml_parser
강남전시장 02-111-1111 (김태연)
삼성전시장 02-222-2222 (구하라)

프로그래밍에 도움되길 바랍니다~

수정 사항

엘리먼트 값이 없는 경우 에러가 발생하는 문제를 해결하기 위해서 showrooms_xml_parser.m의 found 메소드 안에 _elementStack의 마지막 요소 제거 코드를 didEnd로 옮겼습니다.

그런데 요즘 왠만한 앱에는 HTTP를 통해서 XML 데이터를 가져와서 보여주는 기능이 들어가는 데 막상 개발 참고하려고 구글 검색해보면 마땅한 예제가 없어서 간단하게 예제를 작성해보았습니다.

요청하는 XML 문서(hello.xml)는 아래와 같이 작성했습니다.

<?xml version="1.0" encoding="UTF-8" ?>
 
<showrooms>
  <showroom><name>강남전시장</name><phone_number>02-111-1111</phone_number></showroom>
  <showroom><name>삼성전시장</name><phone_number>02-222-2222</phone_number></showroom>
  <showroom><name>한남전시장</name><phone_number>02-333-3333</phone_number></showroom>
</showrooms>

해당 XML 데이터를 HTTP를 통해서 가져와서 처리하는 예제는 아래와 같습니다. 간단하게 실행 되는 것을 확인하기 위해서 컨솔 창에서 돌아가도록 작성했습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

#import <Foundation/Foundation.h>
 
 
int main( int argc, char* argv[] )
{
  NSAutoreleasePool* pool = [ NSAutoreleasePool new ];
  NSURL* url = [ NSURL URLWithString: @"http://www,yourserver.com/hello.xml" ];
  NSError* error;
  NSXMLDocument* xmlDocument = [ [ NSXMLDocument alloc ] 
    initWithContentsOfURL: url
    options: ( NSXMLNodePreserveWhitespace | NSXMLNodePreserveCDATA )
    error: &error ];
 
  if ( nil != error )
  {
    NSLog( @"%@", [ error localizedDescription ] );
    [ pool drain ];
    return 0;
  }
 
  NSXMLNode* rootElement = [ xmlDocument rootElement ];
  NSArray* showrooms = [ rootElement children ];
 
  int i, count = [ showrooms count ];
  for ( i = 0; i < count; ++i ) 
  {
    NSXMLNode* showroomNode = [ showrooms objectAtIndex: i ];
    NSXMLNode* nameNode = [ showroomNode childAtIndex: 0 ];
 
    NSArray* nodes = [ showroomNode nodesForXPath: @"phone_number" error: nil ];
    NSXMLNode* phoneNumberNode = nil;
    if ( 1 == [ nodes count ] )
    {
      phoneNumberNode = [ nodes objectAtIndex: 0 ];
    }
 
    NSLog( @"%@ (%@)", [ nameNode stringValue ], [ phoneNumberNode stringValue ] );
  }
 
  [ xmlDocument release ];
  [ url release ];
 
  [ pool drain ];
  return 0;
}

예제에서 특별히 어려운 내용은 없습니다. NSXMLDocument 클래스가 HTTP를 지원하기 때문에 initWithContentsOfURL 메소드를 호출하기만 하면 됩니다. 그리고 아이폰 런타임 환경에서는 가비지 컬렉션이 지원되지 않기 때문에 NSAutoreleasePool 클래스를 이용해서 메모리 관리를 하였습니다.

예제에서 3가지 다른 방법으로 자식 노드에 접근하고 있습니다. 각각 children, objectAtIndex, nodesForXPath 메소드를 이용합니다. 가장 일반적인 방법은 nodesForXPath을 이용하는 방법입니다. 약간의 성능 문제가 있을 수도 있지만 대부분의 경우 처리하는 XML 데이터의 량이 많이 않기 때문에 신경 쓰지 않아도 될 듯 합니다. 반면 objectAtIndex 메소드를 사용하는 경우 성능은 향상될 수 있겠지만 XML 문법에 종속적이기 때문에 그리 권장할만한 방법은 아닙니다.

해당 파일을 컴파일하는 쉘 구문은 아래와 같습니다.

$ gcc -framework Foundation hello.m -o hello

실행 결과 화면은 아래와 같습니다.

$ ./hello
강남전시장 (02-111-1111)
삼성전시장 (02-222-2222)
한남전시장 (02-333-3333)

프로그래밍에 도움되길 바랍니다~

[ 수정 사항 ]
조사해 본 결과 NSXMLDocument 클래스는 iPhone SDK에 제외되어 있습니다. 따라서 위 예제는 OS X 애플리케이션에서만 동작합니다. 빠른 시일 내에 iPhone에서 돌아가는 예제를 작성해서 올리도록 하겠습니다. iPhone은 iPhone, HTTP로 XML 데이터 요청 및 처리 예제를 참고하세요~

몇일전 워드프레스를 2.9.1버전으로 업그레이드 했습니다. 저희 서버는 SFTP를 사용하기 때문에 자동 업그레이드가 실행이 안되서 다소 귀찮지만 수동으로 업그레이드 했습니다.  그나저나 처음에는 SFTP가 마냥 좋은 줄 알았는데 몇가지 단점도 있고해서 FTPS도 한번 고려해봐야 겠네요.

아무튼 워드프레스 업그레이드 하면서 트위터 플러그인도 몇가지 추가해봤습니다. 아무래도 블로그보다는 트위터에 포스팅을 많이 하기 때문에 포스팅이 빈한 블로그를 보완하기 위해 사이드바에 트위터 위젯을 추가했습니다. 처음에는 구글링의 가장 상단에 나오는 Twitter Tools라는 플러그인을 설치했습니다. 그런데 기능이 너무 많고 무거워서 너무 무거운게 제 취향이 아니었습니다.

그래서 Twitter for Wordpress를 설치했는데 기능도 단순하고 옵션도 적당해서 일단 제 마음에는 들었습니다. 하지만 처음 페이지를 렌더링할 때 다소 지연(delay)가 발생합니다. 아마도 트위터로부터 정보를 가져와서 캐싱하는데 시간이 좀 걸리는 것 같습니다. 일단 캐싱되면 빠르게 렌더링이 되지만 거슬려서 다른 플러그인을 찾아보았습니다.

결국 Twitter Wordpress Sidebar Widget이라는 플러그인을 설치했습니다. Twitter for Wordpress보다는 옵션이 부족하지만 렌더링 시간이 거슬릴 정도는 아닙니다. 그런데 트윗한 시각을 ‘2 house ago’ 형식으로 보여주는데 포스팅 시각이 그리 중요한 것 같지는 않아서 php 소스를 살짝 고쳐서 ‘#’로 표시되도록 했습니다.

트위터 위젯은 사이드바 가장 상단에 배치하였습니다. 아무래도 가장 업데이트가 자주 발생하는 정보인 만큼 우선순위를 가장 높였습니다.  그다음 최근 글, 태그, 월별 목록 순으로 위젯을 배치하였습니다. 블로그롤(링크 목록) 위젯은는 트위터 위젯과 다소 중복적으로 우선순위를 낮췄습니다.

그리고 Tweet This라는 플러그인도 설치했습니다. 이 플러그인을 설치하면 글 아래에 ‘Tweet this’라는 버튼이 표시됩니다. 이 버튼을 클릭하면 현재 보고 있을 글을 트위터로 포스팅할 수 있습니다. 그리고 제가 블로그에 포스팅하면 자동으로 트위터에 URL과 제목을 포스팅해주는 기능도 있습니다.

별건 아니지만 그래도 설치해놓고 보니 뭔가 작은 성취감을 느낄 수 있었습니다ㅎ. 당분간은 열심히 트위팅을 할 것 같습니다~

그런데 오늘 혹시나 하는 마음에 크롬 확장 프로그램(extension)을 찾아보니 userContent라는 확장 프로그램이 있었습니다. 내용을 대충 읽어보니 사용자가 지정한 CSS를 모든 웹 페이지에 적용하는 확장 프로그램인 듯해서 설치를 진행해봤습니다.

우선 2010년 1월 현재 안정 채널(stable channel, 크롬 프로젝트에서는 버전 대신 채널이라는 용어을 사용하고 있네요)은 버전 3.x으로 확장 프로그램 기능을 지원하지 않습니다.  그래서 크롬 프로젝트 홈페이지에 가보니 베타 채널과 개발 채널을 설치할 수 있더군요. 아무래도 베타 채널이 조금 더 안정적이기 때문에 베타 채널을 설치했는데 다행이 베타 채널(ver 4.0)은 확장 프로그램을 지원하더군요.

그리고 userContent 확장 프로그램을 설치했습니다. 아직 사용자 CSS를 지정하지 않았기 때문에 웹 페이지를 열어도 아무런 변화가 없었습니다. ‘도구 메뉴 > 확장 프로그램’을 선택하면 확장 프로그램 페이지가 열리고 userContent 항목의 옵션 버튼을 클릭하면 사용자 CSS 입력 페이지가 열립니다.

* { font-family : '나눔고딕' !important; }

편집 창에 위 내용을 입력한 후 저장합니다. 그러면 크롬으로 여는 모든 페이지에 나눔고딕이 적용됩니다. 당연한 얘기지만 PC에 나눔고딕이 설치되어 있어야 합니다.

CSS 구문을 간단하게 살펴보면 *는 전체 선택자(universal selector)이며 해당 구문은 모든 엘리먼트(element)에 나눔고딕을 글꼴로 적용해라는 내용입니다. (만약 맑은고딕을 적용하려면 ‘나눔고딕’ 대신 ‘맑은 고딕’이라고 입력합니다.)  !important는 사용자 스타일의 우선 순위를 높게 합니다. 기본적으로 제작자(author)가 지정한  스타일이 사용자 스타일보다 우선 순위가 높습니다. 그러나 !important가 선언된 스타일의 경우 사용자 스타일이 더 높은 우선 순위를 갖게됩니다. 그래서 제작자 지정한 글꼴은 무시되고 사용자 지정한 나눔고딕이 웹 페이지에 적용됩니다.

* { font-family : sans-serif !important; }

사용자 스타일을 위에 내용으로 저장하면 브라우저에서 지정한 산세리프체 글꼴이 페이지에 적용됩니다. 이 방법은 사용자 지정 글꼴을 변경할 때 CSS 구분을 직접 편집하는 않고 브라우저가 지원하는 옵션 기능을 이용하기 때문에 CSS 문법에 익숙하지 않은 사용자들이 쉽게 사용할 수 있습니다. 사용자 지정 글꼴을 변경하려면 ‘기능 메뉴 > 옵션 > 고급설정 > 언어와 글꼴’에서 변경할 수 있습니다.

파이어폭스도 좋은 브라우저이긴 하지만 개인적으로 빠른 랜더링과 UI의 간결함 때문에 크롬을 더 좋아합니다. 그러나 지금까지는 크롬에 글꼴을 강제하는 기능이 없어 파이어폭스를 메인 브라우저로 사용하고 있었습니다. 하지만 크롬 4.0부터는 사용자 스타일 지정할 수 있기 때문에 더이상 크롬을 메인 브라우저로 사용하지 않을 이유가 없습니다. 크롬 좋아요~!

[ 추가 사항 ]
전체 선택자를 사용하는 경우 pre 엘리먼트에도 스타일이 적용됩니다. 그런데 pre 엘리먼트는 주로 프로그램 소스 코드를 출력할 때 사용되며 소스 코드는 고정폭 글꼴이 적용되는 것이 좋을 것 같아서 pre, code, samp 엘리먼트를 제외한 모든 block 엘리먼트와 inline 엘리먼트에 적용되도록 수정하였습니다.

p, h1, h2, h3, h4, h5, h6, ul, ol, dl, div, blockquote, form, hr, table, 
  fieldset, address, li, dt, dd, td, tt, i, b, big, small, em, string, 
  dfn, kbd, var, cite, abbr, acronym, a, q, sub, sup, span, bdo, input, 
  select, textarea, label, button, font 
{
  font-family : sans-serif !important;
}

좁은 의미에서 REST는 ROA(Resource-Oriented Architecture)라고 볼 수 있습니다. 마치 객체 지향에서 모든 것을 객체(클래스)로 정의하 듯이 ROA에서는 서비스내에 의미를 가질만한 요소들을 리소스(resource) 단위로 정의합니다. 그리고 리소스가 의미를 가지기 위해서는 리소스의 이름이 필요하며 그 이름을 URI라고 합니다. 참고로 URI와 URL은 같은 걸로 보면됩니다.

그런데 리소스만으로는 서비스의 모든 URI를 표현할 수 없습니다. 모든 내용이 그 내용을 보여주는 형식을 필요로 하듯이 리소스도 리소스를 보여주는 형식이 필요합니다. 리소스를 보여주는 형식을 리프리젠테이션스(representaions)라고 합니다. 그리고 URI는 리소스와 리프리젠테이션의 조합으로 만들어집니다. 예를 들어 레일스에서 아래와 같은 URI 관례가 있습니다.

• /orders
• /orders/1
• /orders/new
• /orders/1/edit

‘/orders’과 ‘/orders/1′처럼 리소스만으로 표현된 URI가 있는가 하면 ‘/orders/new’와 ‘/orders/1/edit’처럼 리소스와 리프리젠테이션이 조합으로 구성된 URI도 있습니다.

일반적으로 리소스를 대상으로 할 수 있는 기본적인 조작(operation)은 몇가지 정해져 있습니다. 흔히 이것들을 CRUD(Create, Read, Update, Delete)라고 하며 레일스에서 정해놓은 CRUD 관련 URI는 아래와 같습니다.

• List : GET /orders
• Create Form : GET /orders/new
• Create : POST /orders
• Read : GET /orders/1
• Update Form : GET /orders/1/edit
• Update : PUT /orders/1
• Delete : DELETE /orders/1

여기서 주목할만 것은 Create, Update, Delete의 경우 별도의 URI를 갖지 않으며 리소스 URI를 요청하는 방식(method)를 달리 가져갔다는 점입니다. 리소스를 GET으로 요청하면 해당 리소스의 리프리젠테이션을 기대하게 되며 리소스를 POST로 요청하면 해당 새로운 리소스를 추가합니다. 마찬가지로 리소스를 PUT으로 요청하면 해당 리소스를 수정하는 것이며 DELETE 방식으로 요청하면 삭제하는 것을 의미합니다.

이러한 기본 규칙을 통해서 URI는 통일성을 가지게 됩니다. 그리고 이 통일성을 좁은 의미에서 RESTful이라 할 수 있습니다. 나아가 이러한 통일성은 개발 효율로 이어집니다. 새로운 서비스의 API를 접할 때 그 서비스가 RESTful하다면 URI의 기본 규칙이 동일하기 때문에 API 학습량이 줄어들기 때문입니다. 아마도 이러한 점이 관례를 중시하는 레일스가 적극적으로 REST를 도입한 이유가 아닐까 싶습니다.

그런데 서비스 기능 중에는 기본적으로 정의된 CRUD 이외의 것들이 있을 수 있습니다. 예를 들어, 단순하게 주문 목록을 보여주는 기능을 List라 하고 목록과 달리 주문과 주문 품목을 함께 보여주는 기능을 Inquiry라고 정합니다. 이때 Inquiry 리프리젠테이션의 URI는 아래와 같이 2가지로 생각해볼 수 있습니다.

• GET /orders?view=inquiry
• GET /orders/inquiry

앞에 것은 쿼리스트링에 리프리젠테이션(view) 정보를 넘기는 경우이며 뒤에 것은 URI에 리프리젠테이션을 명시한 경우입니다. 사실 어느 것으로 하던 상관은 없다고 봅니다. 다만 앞의 것의 경우 List와 Inquiry가 동일하게 주문 목록을 보여준다는 쪽에 무게를 실은 반면에 뒤에 것은 둘이 서로 다른 리프젠테이션이라는 것을 조금 더 명시적으로 표시한 것입니다. 저희 팀의 경우 뒤에 방식을 선택했는데 사용자들이 보기에 List과 Inquiry은 서로 다른 페이지라고 느낄 것이라고 판단했기 때문입니다.

지금까지 REST를 공부하면서 익혔던 것들을 정리해보았습니다. 참고로 RESTful Web Services을 보고 있는데 아직 중간 쯤 읽은 상태라 정리한 내용 중에 틀린 부분이 있을 수도 있으니 기회가 되면 덧글 좀 남겨주세요~

원래 파이어폭스와 크롬을 사용하기 때문에 웹 서핑에 큰 어려움은 없었습니다. 그러나 국민은행 인터넷 뱅킹은 정상적으로 진행할 수 없었습니다(ActiveX 정말 싫다). 그런데 메인보드 포함된 사운드 장치의 드라이버가 정상적으로 설치되지 않았습니다. ASUS 홈페이지에 가봤지만 윈도우즈 7용 드라이버는 없었습니다. 사운드 장치가 비정상적이라 게임을 설치도 해보지 않았습니다.

XP보다 스타일이 좋고 성능도 나쁘지 않아서 윈도우즈 7으로 넘어갈까 했지만 아직은 이른 듯 합니다. 결국 XP 다시 깔아야겠습니다.