Archive for August 2008
장난감 또 하나.
장난감을 또 하나 만들었다. 장난감 이름은 DON. 돈이다. 돈을 어디에 얼마를 썼는지 쓴것만 관리해주는 초간단 유틸이라 하겠다. Core Data는 이제 더이상 손대지 않으려고 하다가… 어젯밤에 잠이 안오는 관계로 두시간 만지작 거렸더니 반정도 완성.. -_-;; 끝내지 않으면 괜히 헛짓거리 한것 같아서 오늘 초간단 ‘주말 프로젝트’로 완성을 시켜버렸다.
앞으로 추가 하고 싶은 것은 iCal 연동 기능과 챠트/그래프 기능. iCal db는 어떻게 접근하는지 전에 해봤기때문에 알고 있는것이고.. 역시 챠트나 그래프는 Quartz Composition을 활용하고 싶은데.. 어찌 챠트는 만들게 될까 말까 모르겠다.
한글 타자연습 응용프로그램 리뷰
cocoadev.co.kr운영자분이 만든 Duksuri. 그리고 wordpress OS X Software Directory인가.. 아무튼 여기 링크를 통해 알게된 Prin_E님이 만들었다는 Taza. 시험준비는 않고 심심? 한 나머지.. (간뎅이가 부은거 맞다.. 시험을 코앞에 두고 심심하다니..-_-) 다운받아 잠시! 가지고 놀아봤다.
먼저 Duksuri. 한마디로 타자 연습이라기보다는 게임이라는게 맞을것 같다. 구름위에서 왔다갔다하는 독수리.. 또는 덕수리가 하늘위에서 떨어뜨리는 떵인지 뭣인지에 적힌 한글을 제대로 입력해서 진한 갈색의 ‘그것’을 파괴시킴으로서 어떻게 바다환경을 보호해 보자는 환경친화적인 타자게임인것 같다. 그냥 1단계만 해봤지만 그리 나쁘지는 않은듯. 패키지 속을 보니 온통 png 인것이 눈에 띈다.
Prin_E님은 예전에 케이머그여기서도 활동하는것을 본적이 있는데, 당시 타자 연습기를 만들겠다더니 베타라를 꼬리표를 붙여 만들어낸것 같다. (이상하게도 화면에는 베타, status bar가 있는 부분에는 알파란다..) 아무튼, 인터페이스를 보면 한컴 타자연습기를 맥에다 심고 싶어한것 같다. 패키지를 열어보니 리소스 폴더 아래에 무슨 바이너리 파일이 좍 늘어서 있다. 키보드 이벤트 훅을 위해 한것인가 싶은데.. 이렇게 할 필요가 있었을까 싶기도 하고.. 아무튼, 모든게 txt파일로 번들안에 위치하고 있는만큼 짧은 문장이든 뭐든 타자연습을 하고자 하는 원본 텍스트의 확장성은 아직 생각하지 않은것 같다.
원본 텍스트를 열어보니 한글이 죄다 깨져 나온다. 순간 내 입가에 번지는 웃음.. 한글 텍스트 인코딩을 바꿔주는것을 만들어볼까 여러번 생각했었는데 어디서 다른 인코딩으로 된 한글 텍스트를 그것도 많이.. 그리고 결과값을 대충이나마 잘 아는 것을 구할수 있을까 했는데 정말 잘된것 같다.
결론은 두 타자연습기/게임모두 잘 만들어진 타자연습기이긴 하지만, MS 윈도우즈 응용프로그램을 만드는 틀에서 조금도 벗어나지 못했다는 것이다. 어디선가 모르게 본듯 하지만 기억을 더듬어 올라가면 윈도우 플랫폼에서 봤던 응용프로그램과 모든것이 흡사하다. 당연히 다른 OS X 응용프로그램과는 상당한 이질감이 느껴진다. 한눈에 그냥 보기에는 맥용 응용프로그램인지조차 분간하기 힘들정도. 어찌보면 악평인것 같기도 하지만… 아쉬운 마음에 몇마디 해봤다. -_-;;
XIB와 NIB
조금전 포스트에 언급한것과 같이 cocoadev.co.kr을 둘러봤을때 XIB에 관한 포스트가 있어 간단히 읽어봤다. 그런데 XIB가 XML형태라는것 외에는 별다른 내용이 없는것 같아 이쪽.. 내 블로그에다 약간 첨언하고자 한다.
XIB는 Xcode 3.1이 되면서 새로 생긴것이 아니라 사실 Xcode 3.0에서부터 있어왔다. XIB는 coocadev.co.kr에서 말한대로 XML 형태의 파일이다. 그런데 왜? 왜 가만히 잘있는 NIB을 XIB로 바꿨을까?
애플이 호환성 문제로 가장 골치아파 하는것중 하나가 바로 이 Bundle이다. HFS에서 지정하는 metadata가 있어야 제대로 인식되고 사용되는 이 Bundle이 왜 새삼 문제가 되는가 하면.. 비슷한 형태의 응용프로그램과는 다르게 Bundle은 소스코드의 일부분이라는것이다. 소스코드의 일부분이기에 Subversion과 같은 SCM을 통해 웹에 업로드되어야 하고 다운로드 받아야 한다는것. 그런데 결정적인 골칫거리는 웹을 왔다갔다 하면서 Bundle의 metadata가 호환성의 문제로 없어질수도 있다는것이다. 해서 애플에서 부랴부랴 XML형태의 flat file인 XIB 포맷을 만들어낸것이다.
XIB와 NIB은 100% 같다고 보면 된다. 물론 개발자에게만. NIB의 한가지 단점은 응용프로그램으로 만들어지고 난 뒤 해커? 들에 의해 마음대로 수정될수 있다는것이었다. 몇몇 애플 응용프로그램이 가진 NIB파일은 compile되었다면서 Interface builder에서 로딩하지 않지만, 대부분의 맥 응용프로그램이 포함하고 있는 NIB파일은 언제든지 수정가능한 형태로 배포되는것이 사실이다.
그렇지만 응용프로그램 번들에 포함되어 있는 XIB는 열리지 않는다. 응용프로그램이 일단 컴파일 되면 Interface Builder에서 열어볼수가 없는것이다. 개발자로서는 반가운 소식이라 생각되는데, 아무튼 그렇다. 개발자로서 XIB 사용을 회피해야 할 이유는 NIB보다 파일사이즈가 ‘아주’약간 커진다는것. XIB를 쓰지 않을 이유는 사실상 없는것이다.
새로운 맥 개발관련 사이트.
네이버 카페도 사이트! 라 쳐주는가 모르겠다. 아무튼, OS X개발의 불모지 인것 같은 우리나라에 또다른 맥 개발관련 그룹이 생긴것 같다. 맥을 사용하는 많은 사람들이 가입해있거나 또 알고 있듯이 나 역시도 네이버 맥북을 쓰는 사람들 이라는 카페를 자주 이용하는데, 거기서 모임이 하나 가지치기 형식으로 탄생한것.
둘러봤다. 이제 처음 시작해서 그런지 온통 가입인사다. 가입을 하지 않으면 가입인사조차 볼수가 없다. 가입을 했지만 가입인사를 제외한 모든것.. 별로 있지도 않는 그것들을 보려면 또다시 정회원이 되어야 한단다. 장난치나 -_-;; 하는 소리가 입밖으로 저절로 나온다. 자료라 해봤자.. 인터넷에서 누구에게나 무료로 공개하면서 유명해진 Become an Xcoder와 같은것들. 별것도 아닌걸 상당히 감싸안고 있구나 싶다.
여기저기 이런저런 커뮤니티를 보건대 OS X 코코아 개발을 하고자 하는 사람은 꽤 되는듯 해 보이는데 정작 쓸만한 내용은 없는것 같기도 하다. osxdev.org역시 위키라는것을 만들어 내용을 공유하고자 하지만 위키.. 모르겠다. 코코아 책은 아니지만 예전에 돈주고 산 번역본 책도 역시 읽다가 지쳐서 원문을 보고 속이 시원했었던 만큼 난 그냥 영문을 읽는게 더 쉬운것 같다. -_-;; 아무튼, 번역하면서 원문이 더 ‘이해불가’가 되는경우가 허다하다.
cocoadev.co.kr 역시 둘러봤다. 오래전에 포스트를 한번 읽은 적이 있는곳. 8월 들어서 Xcode 3.1에 관한 포스트가 올라오고.. 루비도 이야기 하는것을 보면서 웃기게도 내가 올린 포스트들과 주제가 좀 비슷하다는 느낌이 팍팍. 그래도 글만써대는 내 포스트와는 달리 그곳에는 상당히 비주얼한 포스트가 올라와 있었다. 역시 한국 사람들에게는 비주얼하게 어필해야 하는것인가 싶다.
아무튼 결론은 새로 생긴 네이버 카페. 여자회원없다고 여자회원을 가입시키면 어떠한 특혜?를 주겠다는 애들 장난같은 사이트. 자료가 없어서가 아니라.. 운영하는 방법등등에 대한 첫인상은 상당히 ‘별로’다. 내 블로그나 신경써야겠다.
DashCode
Xcode3.1에서 아이폰 프로젝트 메뉴가 생긴것과 마찬가지로 대쉬코드에도 역시 아이폰 프로젝트 생성 매뉴가 생겼다. 며칠전 포스트에서 다뤘던 아이폰 개발 시작하기 동영상을 보았다면 다들 알겠지만, 아이폰 개발을 하는 방법은 크게 두가지다. 첫번째는 코코아 (터치) 응용프로그램을 만드는 것이고 두번재는 ‘아이폰 전용’ 웹페이지를 만드는 것. 이미 타이거에서 부터 선보인 대쉬보드 위젯을 만드는것과 거의 동일한 방법으로 아이폰 전용 웹 응용프로그램을 제작하는 것인데, 겉으로 보이는 UI에는 둘의 차이가 없으나 다만 후자는 사파리 안에서 실행된다는것만 다르다.
Xcode가 아닌 대쉬보드에서 html과 자바 스크립트로 제작되는 응용프로그램이라해서 간단히 봤다간 큰코다치기 딱 좋을것이다. 대쉬보드에서 제공하는 텝플릿으로 생성되는 유틸리티 응용프로그램은 코코아로 제작하는 응용프로그램에 비해 손색이 없을 정도의 기능을 담고 있으니 말이다. 자바 스크립트를 보는 즉시 다들 알아채겠지만, 자바 스크립트로 sqlite 데이터 베이스를 엑세스하고 있는것을 볼수 있다. 코코아 응용프로그램 역시 아이폰 플랫폼에서는 sqlite를 사용하도록 권장을 하고 있는만큼 대쉬코드를 사용한다고 해서 기능상 제한이 있는 ‘장난감’응용프로그램만 만들어야 하는것이 아니라는 것이다. OS X플랫폼에서 보는 위젯과 일반 코코아 응용프로그램과의 차이가 아이폰 플랫폼에서는 없어지는것이라 보는것이 맞을지도 모르겠다. 대쉬보드에서 제작하는 웹 응용프로그램은 landscape, portrait view에도 대응할수 있으므로 사파리 안에서 운용된다는것 외에는 사용자가 느끼는 기능상의 차이는 정말 없을듯 하다.
개인적으로는 자바 스크립트를 사용한지가 한참 오래된데다가 그동안 대쉬보드 위젯을 만드는것에도 관심이 없었기에 대쉬코드를 사용해서 아이폰 응용프로그램을 만들일은 없을것 같지만, 한국에 무수히 많은 웹프로그래머들에게는 이보다 좋은 아이폰 개발툴이 있을까 싶다. 한번도 데스크탑 응용프로그램을 만들어본적이 없는 웹프로그래머에게는 Objective-C와 코코아를 배우지 않아도 된다는 해방감과 함께 단계별로 해야할 일을 체크해주기도 하고 거기다 배포까지 편리하게 도와주는 대쉬코드를 만나는 즐거움이 틀림없이 쏠솔할것이다.
Quartz Composer

Xcode Tools중 Xcode 다음으로 가장 좋아하는.. (잘다룬다는 것이 아니라.. 단순히 좋아하는..) 툴이 바로 Quartz Composer다. Quartz Composer를 가지고 놀다보면 눈앞에 펼쳐지는 신기함에 시간가는줄을 모르기 때문이다.
Quartz Composer를 매번 들여다 보는 또다른 이유는, 화면 보호기를 만드는것은 물론 코코아 응용프로그램에서도 요긴하게 사용할수 있기때문이다. 아이폰 응용프로그램 에서도 역시 Quartz Composition을 사용할수 있으니 조금씩 조금씩 놀아가며.. -_-;; 배워놓으면 나중에 다 피가되고 살이되리라는 생각이 있다.
물론 코코아에서 composition을 불러다 사용하는 기본적인 방법은 이미 터득한지 오래다. 정작 문제는 스스로 쓸만한 composition을 만들어내는 단계에 오르려니 이거 꽤나 힘들다. 머리가 나빠서일수도 있고.. 창의력이 없는 굳어버린 감각 때문일수도 있겠지만.. 굳이 핑계를 대자면 예제파일을 들여다 볼때마다 매번 입맛이 뚝뚝 떨어지게하는 Ugliness덕분인것 같다.
Ruby 개발자왈 Perl이 Ugly하다 했다. 그렇지만 Quartz Composer는 단순한 ugliness를 넘어서 적어도 나에게는 험오감마져 주는듯 하다. 매번 붙잡고 갖고 놀다가.. 어떻게 만들었나 좀 배워볼까? 하면 헉. 하는 소리가 나오며 딱 쳐다 보기가 싫어지니.. -_-;; 도대체 언제 득도를 할지 까마득하기만 하다. 제발 애플에서 이것좀 이쁘게 만들어주면 안될까?
Xcode Tools
맥 개발도구라고 하면 모두다 Xcode를 꼽는다. 그런데 정작 설치하는것은 Xcode Tools. 그렇다.. 그냥 엑스코드가 아닌 북수형태의 툴즈 라는 것을 인지하는 사람은 그리 많지 않은듯하다.
/Developer/Applications 아래를 둘러본 사람은 상당히 많을것 같다. 그렇지만 Utilities 아래에 있는 도구들에게 관심가지는 사람은 Xcode를 사용하는 사람중 몇이나 될까. 코코아 시작하기 문서에서 부터 이 유틸리티들에 대해서 자세히 사용법을 설명하는 문서를 쉽게 찾아보기도 힘들거니와 가장 큰 이유는 이런 유틸리티가 없어도 ‘개발’이 가능하다는 이유때문이지 않겠나 한다.
그렇지만 유틸리티. 안써도 되지만 쓰면 상당히 편한것들이 많다. 나도 역시 한번도 안써본것들이 많지만.. 무엇이 있는지 정도는 알아보기 위해 자주자주 이것저것 갖고 노는 편이다. 물론 Help메뉴가 준비되지 않았다.. 기본 About 창 등등 애플에서 유일하게 ‘알아서 쓰라’는 식으로 배포하는 도구들이긴 하지만 대충 둘러보면 어떠한 도구인지, 사용법은 어떠한지 알아보는것은 그리 어렵지 않다.
드디어..
A-Bike Plus가 드디어 완성됐나보다. 그동안 계속 사이트문을 닫아놓고 있더니.. 오늘 가서 보니 이제 제대로 주문을 받고 있다. 지금 주문을 받기는 해도 9월 8일부터 배송한다는데.. 정작 문제는 뻐대밖에 없는 자전거가 너무 비싸다는것. “Only 199.99파운드” 라는데… Only?? 199.99 파운드면.. 배송비를 제외하더라도 우리나라돈으로 거의 40만원 -_-;; 달러로 쳐도 $370. 그돈이면 Specialized는 좀 어렵겠지만 웬만큼 쓸만한 MTB를 살수도 있다. 이동이 간편하고 가볍다는것 때문에 하나 장만하려고 벼뤘더니.. 적어도 당분간은 안될것 같다.
Default.png
K/R이 쓴 C 책에서 부터였다고 알고있다. 아무튼, 요즘은 뭐든지 처음 배울때 만들게 되는 Hello World. 역시 Hello World iPhone 예제도 있다. View Based 프로젝트에서 시작한듯한 아주 간단한 iPhone 응용프로그램인데 Default.png의 존재가 참 재밌다.
iPhone Application Tutorial을 보면 응용프로그램이 로딩될때.. 그러니까 화면이 확대되는 동안 보여지는 것은 윈도우라고 하는데.. 사실은 그게 아닌것 같다. Hello World와 2-3가지 프로젝트에서 실험해본 결과 처음 응용프로그램이 로딩될때 보여지는것은 Default.png 이미지 파일이다. 따라서 Hello World의 메인 윈도우에 있는 UIImageView를 지워버려도 달라지는것은 하나도 없다는것이다. 정작 iPhone이나 iPod에서 보면 다를수도 있겠지만 최소한 iPhone Simulator에서는 그렇다.
끝으로 Hello World 응용프로그램을 구경하고 나서 한가지 알아둬야할것은 뭐니뭐니해도 윈도우를 생성한 후에 subview를 지정해주는 방법으로 응용프로그램을 꾸린다는것이다. OS X에서 만드는 코코아 응용프로그램에서는 splitview가 아닌다음에야 이런 방법을 잘 사용하지 않기때문에 처음엔 왜 이런 복잡한 방법을 사용할까 의문을 가질수도 있겠지만 (난 그랬다..-_-) 플랫폼이 iPhone이라는 사실을 생각한다면 아마 누구나 곧 이해가 갈것이다.
ADC 문서를 가까이 두자.
iPhone SDK를 설치하면 약 33개의 예제코드도 같이 설치된다. 기존 OS X 예제코드가 있는 곳에 iPhone이라는 폴더가 생성되기는 하지만 iPhone 예제코드는 iPhone SDK 문서와 함께 있다는 내용의 txt파일 하나만 달랑 있을뿐이다. 항상 ‘읽는것’을 강조하는 나역시도 txt 파일의 내용을 읽지도 않고 닫아버리는 바람에 33개 예제를 일일이 다 다운받았는데, 다른사람은 그러는 일이 없기를 바란다. 그리 오래걸리는 작업은 아니지만, 아무래도 좀 창피한 짓이긴 하기 때문.
Xcode에서 Documentation 메뉴를 이용해 ADC 문서를 읽을수도 있지만 난 주로 Safari를 통해 여러가지 programming guide를 읽는다. String 검색을 했을때에 Safari가 눈에 잘 띄게 검색해주는 것은 물론 Xcode Documentation Viewer의 왼쪽 사이드 바를 없앤다는것 하나만으로도 문서를 읽을수 있는 화면의 크기를 늘릴수가 있어서 글읽기가 한결 편하기 때문이다. 해서 Xcode Documentation Viewer는 주로 코딩을 하면서 특정 Class나 Framework API를 검색할때에만 사용한다.
Safari를 이용해 여러가지 Programming Guide를 읽고자 한다면 그것들이 어디에 설치되어 있는지를 알아야 한다. 그렇지만 공교롭게도 애플은 당연히 Xcode에서 모든 문서를 읽을것이라 생각했었는지 ADC문서를 꽁꽁.. 은 아니고 살짝 감춰놓았다. ADC문서를 Docset이라는 번들에다 가둬놓았는데 그래서인지 정작 필요한 html페이지는 파일시스템 깊숙한곳에 위치하고 있다.
따라서, 나와 비슷한 성향의 사람이라면.. Core Library Reference와 Phone Reference Library의 인덱스 페이지, 그리고 OS X와 iPhone 예제코드 위치를 가리키는 Alias를 만들어 하나의 폴더에 담은 후 언제든지 볼수 있도록 Finder sidebar에다 얹어놓고 사용하고 싶을것이다. Alias link를 걸어야 하는 위치는 아래와 같다. (오타의 위험이 있는 터미널을 이용하는것보다 Finder를 이용하면 아주 쉽고 정확하게 Alias를 생성할수 있다.)
Core Library Reference 인덱스 페이지:
/Developer/Documentation/Docsets/
com.apple.ADC_Reference_Library.CoreReference.docset/Contents/Resources/
Documents/index.html
iPhone Reference 인덱스 페이지:
/Developer/Platforms/iPhoneOS.platform/Developer/Documentation/DocSets/
com.apple.adc.documentation.AppleiPhone2_0.iPhoneLibrary.docset/Contents/
Resources/Documents/index.html
OS X 예제코드:
/Developer/Examples
iPhone 예제코드:
/Developer/Platforms/iPhoneOS.platform/Developer/Documentation/DocSets/
com.apple.adc.documentation.AppleiPhone2_0.iPhoneLibrary.docset/Contents/
Resources/Documents/samplecode