Extremely Agile

xfig로 그린 그림에 latex 수식 삽입하기

이병준 — Mon, 08 Mar 2010 14:57:21 +0900

xfig로 그린 그림에 latex 수식을 삽입하고 싶을 때가 있습니다. 그럴때는 다음과 같은 절차를 따르면 됩니다. pdflatex을 쓰신다고 가정했지만, 다른 경우에도 비슷하지 않을까 싶습니다.

우선 문서에 \usepackage{graphicx}, \usepackage{color}의 두 가지 패키지를 적용합니다. \documentclass와 \begin{document} 사이입니다.

그런 다음에, xfig로 그림을 그립니다. 텍스트를 넣을 때, 수식 부분은 $\mathcal F(p_{i,j})$와 같이 해서 넣어줍니다. 이렇게 수식을 텍스트 안에 포함시키는 경우, 해당 텍스트 부분을 "Edit" 버튼을 누른 다음 클릭하면 다이얼로그 박스가 뜨는데요. 그 창에 보면 "Special Flag"를 지정하는 콤보박스가 있습니다. 클릭해서 "Special"로 바꾸어 줍니다. 수식을 포함하는 모든 텍스트에 대해서 같은 짓을 반복해 주어야 합니다.

그런 다음에 그림을 저장하고, export합니다. export할 때에는 Language를 "Combined PDF/LaTeX (both parts)"를 선택합니다. 그런 다음 파일 명을 지정하는데, query.pdf와 같이 pdf 확장자를 갖도록 지정합니다.

그러면 파일이 두 개 만들어집니다. query.pdf와 query.pdf_t의 두 개 입니다.

이제 이 그림을 *.tex 문서 안에 포함시켜야 합니다. 포함시킬 때에는 다음과 같이 합니다.

\begin{figure}[t]

\centerline{

\scalebox{0.63}{

\input{query.pdf_t}

}

\caption{Communication using the result of a \emph{query}}

\label{query}

\end{figure}

이렇게 하면 그림 안에 포함시킨 모든 수식이 LaTeX 수식으로 바뀌어 포함됩니다.

문제가 생기면 보통 \usepackage를 제대로 해 주지 않아서 생기는 문제입니다. 필요한 패키지가 전부 문서에 포함되었다면, 특별한 문제 없이 제대로 되어야 합니다.

별건 아닌 팁인데, 하다 보니까 필요할 때 까먹기 쉬운 팁이라 포스팅해 봅니다. ^^ 이렇게 해서 만든 그림은 다음과 같은 모습을 하고 있습니다.

올려놓고 보니까 그림이 좀 작군요. ㅎㅎ

도움이 되셨기를...

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

최근 근황 (2월 23일 현재)

이병준 — Tue, 23 Feb 2010 22:07:30 +0900

굵직한 것들만 나열해 보면....

드디어 Fit for developing software의 번역서가 "Fit: 통합 테스트 프레임워크 - 테스트는 소통이다" 라는 제목으로 번역 출간됩니다. 작년 반을 이 책과 보낸 것 같은데 드디어 출간이군요. 한편으론 기쁘고 한편으론 씁쓰레 합니다. 다시 들춰보기 두려워서...
iCoffeeBreak라는 이름으로 내놓았던 두 번째 iPhone 어플리케이션을 아이콘 바꾸고 이름만 바꿔 bMessenger라는 이름으로 다시 릴리즈했습니다. 역시 프로그램이 잘 팔릴려면 타겟이 명확해야 하고 그래서 고객의 요구를 읽는 것이 얼마나 중요한지 새삼 깨달았죠. (딱 한개 팔렸다는 ㅎㅎ)
CORD: The Network Management Cloud 라는 제목의 논문의 8페이지 짜리 초고를 만들었습니다. 이 논문을 GLOBECOM 2010 학회에 제출하려고 5페이지로 줄였(날렸)습니다. 3월 15일이 마감이라 시간이 별로 없습니다. 이 논문이 Accept 되면 졸업 점수는 다 채울 것 같군요. 그럼 내년 봄에는 졸업인가...
2월 25일 과제 최종 평가 시연이 있습니다. 꼴랑 사흘 남겨놓고 팀장님이 새로운 시연 안을 주시는 바람에 박이 터집니다만 그래도 꿋꿋이 술먹고 칼퇴근하고 회사에서만 바쁜척 하고 있습니다.
경찰서에서 수사 자문 요청이 왔습니다. 살다보니 별 일을 다 하게 되는군요 ㅎㅎㅎㅎ 누가 누구 소스코드를 그대로 갖다 쓴건지 아닌지 좀 알아봐 달라네요. (누구와 누구가 누구인지는 밝힐 수 없다는 거 ㅎㅎ)

역시 안되는 영어로 논문 쓰는게 제일 어렵군요.

어제는 팀장님하고 둘이서 술을 한잔 했습니다. 같이 3년을 일한 분인데 정작 모시고 술먹으면서 이런 저런 이야기 나눈 적이 '단한번도' 없었더군요.

그래서 기왕 마시는 김에 필름 끊길 때 까지 마셨습니다. ㅎㅎ

그리고 노래방 가서 팀장님은 고래사냥 부르시고 저는 임재범 노래 부르다가 고음 부분에서 정신을 잃었다는 ㅎㅎ 역시 이제 나이가 있어서 노래방 같은데는 그만 다녀야 할듯.

연말도 아니고 연초인데 오만가지 일들로 심란하기 짝이 없어서 술을 꽤 자주 먹게 되네요.

블로그 방치해 둔 지도 꽤 되어서 푸념삼아 몇자 남겨봅니다. 논문 마무리 되는대로 다시 돌아오도록 하겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

iCoffeeBreak, 두번째 iPhone App

이병준 — Sun, 07 Feb 2010 12:21:21 +0900

This program is basically bluetooth-based messenger.

All the participants of a messenger session can share their opinion and contact info with this simple program during their coffee break :-) or any kind of meeting held within the reach of bluetooth network.

The program enables meeting participant to communicate easily, and saves all the conversations as local history. The saved conversations can be sent by email, which enables users to let others know about the meeting result.

The program is useful in almost every situation where text-based communication is needed. But especially effective if you do stand-up meeting frequently.

As all the participants of the meeting can share their opinion instantly, the burdens of taking notes about the meeting is simply reduced.

In the near future, this program will be enhanced to support photo taking & sharing. The enhancement will satisfy everyone who wants to leave the visual record of their meeting. :-)

Have fun! APPSTORE LINK

PS. If you have any question, pleas leave comments.

이 프로그램은 블루투스 메신저 프로그램입니다.

이 프로그램으로 매일 매일 진행하는 모든 형태의 미팅 기록을 남기고, 메일로 전송할 수 있으며, 연락처 정보를 주고받을 수 있습니다. (연락처 정보는 config 메뉴를 통해 설정할 수 있습니다.)

가령 매일 매일 stand-up meeting을 진행하는 개발자라면, 이 응용 프로그램을 통해 자신의 의견을 미팅 참여자에게 전달하고, 그 기록을 자동으로 자신의 iphone에 보관할 수 있습니다.

저장된 기록을 email로 전송할 수도 있기 때문에, 회의록을 남기기 위해 따로 문서 작업을 할 필요도 없습니다. 연락처를 주고받을 수 있는 기능은 명함이 없는 상황에서 유용합니다. 학회가 열리는 장소나 전시회가 열리는 장소에서 미팅 방 이름만 공개하면, 다수에게 자신의 연락처를 즉시 전송할 수 있습니다.

이 프로그램으로 여러 행사에 참여하여 다른 사람들과 의견을 나누는 과정이나, 매일 매일 일상적으로 일어나는 회의의 기록을 남기는 과정의 생산성이 조금이나마 올라가기를 기대합니다. 재미있게 사용해 주세요. 감사합니다.

앱스토어 링크

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

오덩가 말덩가 사이트에서 본 웃기는 이야기

이병준 — Thu, 04 Feb 2010 15:50:32 +0900

프로그래머들의 격언...

1. "오늘까지"라는 말은 "내일 아침까지"라는 말이다.

2. 프로그램은 내가 원하는대로 움직이지 않는다. 타이핑대로 움직인다.

3. 요구 사양은 프로그램을 완성한 후에 추가된다.
기본 사양은 완성품을 고객이 보고 나서 결정된다.
상세 사양은 사용자가 프로그램을 사용해 본 이후에 결정된다.

4. 소프트웨어 설계에는 두 개의 방법이 있다.
하나는 결함이 있을 수 없을 정도로 단순하게 만드는 방법이다.
다른 하나는, 분명한 결함을 눈치채기 어려울 정도로 복잡하게 만드는 방법이다.

5. 코드는 개발 현장에서 사용하는 것이 아니라 납품처에서 사용하는 것이다.
디버그는 납기일까지 하는 것이 아니라, 납품된 이후에 하는 것이다.

6. 프로그래머를 죽이기 위해서는 칼이 필요없다. 프로그램의 요구조건을 3번만 바꾸면 된다.

7. 다른 사람을 믿으라. 그 사람이 해결해줄지도 모른다.
주의사항 - 먼저 자신을 의심해라.

8. 개발에 마지막은 없다. 출시만이 있을 뿐이다.

9. 클라이언트의 요구사항이 제 아무리 뒤늦게 추가되어도 납기일은 변하지 않는다.
이것을「납기 불변의 법칙」이라고 한다.

10. 우리의 고객들은 물과 기능추가를 공짜라고 생각하고 있다.

11. 주머니가 짠 고객일수록 잔소리가 많다.

12. 개발 스케줄은 산수를 무시하며 짜여진다. 영업과는 1＋1=2를 이해하지 못하는 사람의 모임이다.

13. 한 명이 쓰러지면 모두가 쓰러진다.

14. 버그가 너무 심하다? 걱정마라. 어느 순간 그것은 기본 사양이 될 것이다.

15. 좋은 설계는 한 명의 천재보다 세 명의 범재를 요구한다.
나쁜 설계는 백명의 범재보다 한 명의 천재를 요구한다.

16. 고객에게 시스템 엔지니어는 부하이며, 프로그래머는 가축이다.
시스템 엔지니어에게 고객은 돈이다.
프로그래머에게 고객은 보이지 않는 악성 바이러스다.

17. 돈과 시간만 있으면, 그 어떤 시스템이라도 만들 수 있다고 생각하는가?
웃어라. 그 기회는 영원히 주어지지 않는다.

18. 품질은 사양 변경의 수와 규모에 의해, 얼마나 열화될지 결정된다.

19. 영업과는 공상이 실현된다고 생각하는 몽상가이다.
시스템 엔지니어는 넘을 수 없는 벽이 없다고 믿는 모험가이다.
프로그래머와는 몽상가와 모험가에 의해 칠흑의 바다에 내던져진 표류자이다.

20. 유능한 프로그래머가 프로그램 설계개념도를 받아들고 최초로 하는 일은, 프로그램의
목적을 이해하는 것이다. 그리고 그 다음으로 하는 일은, 지정된 방법과 시간 안에는
도저히 그 목적을 완수할 수 없다는 사실을 시스템 엔지니어에게 이해시키는 일이다.

21. 프로그램이란, 운과 감에 의해서 작성되는 기적이다.
운과 감이 없다면, 그 기간 내에 그러한 목표를 실현될 수 있을 리 없다.
따라서 사양 변경은 기적에 트집을 잡는 건방진 행위이며, 사양 추가는 기적이 두 번
일어날 것으로 믿는 무모한 행위이다.

22. 시스템 엔지니어는 지구력, 프로그래머는 순발력.

23. 정시에 퇴근하면, 일이 늘어난다.

24. 완벽한 프로그램은 완벽한 시간과 돈을 필요로 한다.
미국의 국가 예산을 무제한으로 사용하는 NASA마저도, 아직 시간과 돈이 부족하다고 한다.

25. 눈으로 훑어볼 틈이 있다면 움직여라. 뇌세포보다 CPU가 더 해석이 빠르다. 그리고, 그 사이,
쉴 수 있다.

26. 불편함을 버그라고 부를 것인가, 사양 상의 제한 사항이라고 부를 것인가는 남겨진 개발일자와
납기일에 의해 결정된다.

27. 정장 대신 캐쥬얼을 입고 출근하는 "캐쥬얼 데이"를 세간에서는 휴일이나 공휴일이라고 부르는
것 같다.

28. 프로그램은 머리로 기억하지 않는다. 몸으로 기억한다.

29. 내일 쉴 수 있다면 오늘 죽어도 괜찮다.

30. 고객은 거짓말을 한다.
영업은 꿈을 말한다.
시스템 엔지니어는 공상을 이야기한다.
프로그래머는 과묵해진다. (혼잣말은 많아진다)

31.「네, 할 수 있습니다」라고 말하기 전에 10초만 곰곰히 다시 생각해보라.

32. 프로그래머는 1분 생각하고 1일을 코딩에 소비한다.
1시간 생각하고 1시간 코딩하는 대신에 말이다.

33. 납품 이후의 디버그는 버그를 부른다.

34. 세 개의 디버그는 하나의 버그를 낳는다. 이것을 버그의 엔드리스 루프라고 한다.

35. 안 좋은 예감은 반드시 적중한다. 그러나 프로그래머는 그 안 좋은 예감에 반응하지
않는다. 그것은 시스템 엔지니어의 일이다.

36. 아수라장을 해결할 수 있는 방법은 오직, 고객이 돈을 지불하는 것 뿐이다.

37. 아마추어는 버그발견의 천재이다.

38. 아, 그건 마이크로소프트에서만 가능한 주문입니다.

39. 프로그래머가 불만이라고 생각하는 부분은 고객도 반드시 불만이라고 생각한다.

40. 건강하기 때문에, 건강을 해친다.

41. 그건, 당신이 말한 요구조건입니다만.

42. 아, 개발실의 창문은 안 열립니다. 그 이유는 옛날에 한 프로그래머가 그 창문에서***

43. 고객은 최악의 사태를 믿지 않으며, 그 사태에 대한 준비를 악질적인 비용청구라고 생각한다.
시스템 엔지니어는 최악의 사태를 대비하고 준비하려 한다.
프로그래머는 최악의 사태를 누구보다 잘 예상하지만, 무시한다.

44. 만약 다른 직업을 갖게 된다면, 정시퇴근을「도망」이라고 부르지 않는 직업이 좋을 것 같다.

45. 시스템 엔지니어가 프로그래머에게 말하는「상식」은 3시간마다 변한다.

46. 최소한 자기가 쓴 시방서는 읽어주세요.

47. 고객이 시스템 엔지니어에게 사랑받는 방법은, 시스템 개발에는 시간이 곧 돈이라는 사실을
깨닫고 빨리 최종요구조건을 확정하는 것이다.

SE가 고객에게 사랑받는 방법은, 프로그래머에게 미움받는 것이다.

48. 납기일이란, 작업현장이 우리 회사에서 고객의 회사로 바뀌는 날을 의미한다.

49. 가끔 일어나는 버그는 버그가 아니다. 스펙이다.

50. 개발비의 30%는 프로그램의 요구조건을 확정하는데 사용된다.
개발비의 30%는 프로그램의 요구조건을 변경하는데 사용된다.
개발비의 30%는 프로그램의 버그를 잡는데 사용된다.
개발비의 10%만이 프로그램의 개발에 사용된다.

--------------

몇번이 가슴 깊숙히 박히는가...

난 9번과 44번

8

프로그래머들은 마약이 필요 없어

3일 꼴로 환각 체험을 하니까

13

눈앞에 있는 키보드가 눈에 띄지 않는다고,

코딩 하면서 생각한 적 있다

33

눈앞에 있는 것이 키보드 라는 걸 모르게 되는 거야

112

잠시 쉴 요량으로 화장실에 갔더니 변기에 손을 집어 넣고 있는 직장 동료

뭐하는 거야? 라고 물어 보니 똥을 잃어 버렸다면서 울었다.

솔직히 무섭다

나도 결국 이렇게 되는 건가?

160

우선 키보드가 사라져

그리고 모니터가 공중으로 떠오르는 거야

자신이 앉아 있는지 서있는지 모르게 되기 시작해

뭘 하고 있는지, 현실인지 꿈인지 조차 판단되지 않게 되는데

모든 행동이 조건 반사 레벨로 행해지게 되지

이건 정말 나쁜 방향으로 무의 경지다

192

우와, 방금 타이핑 하다가 잠들었다 w

나 환기통에서 잔 적이 있어,

혼자 있고 싶다와 어두운 곳에서 자고 싶다 이 두 가지 조건을 충족할 수 있는

최고의 환경이라 생각해서 환기통에 들어가 잔 적이 있지

한밤중에 한 손에 마우스를 든 직장 동료가

마우스가 사라져서 일을 할 수 없어~ 라면서 환기통 뚜껑을 열어 재꼈을 때는

진심을 이성을 잃었어

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Java와 Windows

이병준 — Fri, 29 Jan 2010 19:29:09 +0900

요즘 시스템 퍼포먼스 성능 튜닝을 하고 있습니다. 제가 개발에 참여한 시스템이 Java로 구현되어 있어서, Java 성능 튜닝을 하는 중입니다.

그런데 작업을 하다가 아주 재미난 현상을 발견했습니다. 쓰레드 (아주 작습니다) 를 아주 빠른 주기로 생성해서 프로세싱을 하는데 (하다가 성능이 잘 안나올 것 같아서 쓰레드 풀을 만들어 쓰고 있습니다) 쓰레드 객체가 new되어서 실제로 run 되는데 까지 16ms가 (정확하게는 15.5ms쯤 되는 것 같습니다) 걸리는 현상이 1초당 20~40회 정도 목격된 것이죠.

이 현상이 최초로 목격된 것은 Windows 2003 서버였는데, 비스타나 Windows 7에서도 똑같았습니다.

그래서 쓰레드를 만드는 부분의 코드만 아주 작은 테스트 프로그램으로 분리한 다음에 Windows 시스템들에서 각각 돌려봤습니다. 똑같더군요. ㅋㅋ

같은 프로그램을 Mac OS X에서 돌려봤습니다. 거기서는 그런 현상이 관측되지 않았습니다. Mac OS X에서 실행한 그래프는 다음과 같습니다. Eclipse를 썼습니다. 프로그램 초반에는 쓰레드 풀과 객체 풀이 초기화되느라 약간의 삽질을 하는 것이 보입니다만, sample 수를 감안한다면 적당한 성능을 보입니다.

Windows 플랫폼에서는 가로줄이 0과 16ms 위치에 두 줄 그어집니다. 이 문제를 해결하기 위해서 웹 써치를 좀 했는데, 아무래도 실제로 성능이 그렇게 나오기 때문에 그런 그래프가 그려진다기 보다는, System.currentTimeMillis() 의 resolution이 Windows에서 떨어지기 때문인 것 같더군요.

이 문제를 workaround하기 위한 한 가지 방법은, (measurement가 중요한 환경이라면) System.currentTimeMillis()를 쓰는 대신 System.nanoTime()을 쓰는 것입니다. 그러면 Windows XP 상에서 다음과 같이 성능 측정 결과가 개선되는 것을 볼 수 있습니다.

Y 축은 nanosecond를 millisecond로 변환한 결과입니다. 측정된 성능은 확연하게 나아졌습니다. (Mac OS X보다 낫다고 하긴 뭐합니다. 이 위에 Mac OS X에 대해 그린 그래프는 System.nanoTime을 써서 그린 그래프가 아니라서 정확한 비교자료가 될 수 없거든요.)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

최근 근황

이병준 — Wed, 06 Jan 2010 17:18:37 +0900

10000 hours - 심심해서 만들어본 아이폰 앱(아이폰,앱,앱스토어) 2009-12-17 15:22:13
또다른 아이폰 앱 구현에 착수. 이번엔 블루투스 기능을 활용할 예정…(아이폰 앱 블루투스) 2009-12-22 09:13:30
아이폰과 블루투스(아이폰 블루투스) 2009-12-22 14:38:27
첫 아이폰 앱, 앱스토어에 등록되다. 근데 너무 허접한걸… 빨리 업데이트 해야할듯….(아이폰 앱 앱스토어) 2009-12-24 10:03:49
두번째 아이폰 어플리케이션 완성. 블루투스 통신 기능을 활용한 Stand-up 미팅용 근거리 메신저 프로그램. 22일날 착수했으니 딱 일주일 걸렸다.(아이폰 앱 블루투스 앱스토어) 2009-12-29 08:53:16
Don't Hope for a Miracle. Make One.(miracle) 2009-12-29 10:57:10
Objective-C에서의 클래스 변수(Objective-C 클래스 변수) 2009-12-30 20:19:41
심심해서 만들어본 아이폰 앱 사흘동안 열 두개 팔리다. 이정도면 성공인가? ㅋㅋ(아이폰 앱 앱스토어) 2009-12-31 13:21:52
나흘동안 열 여섯개. ㅋㅋ(아이폰 앱 앱스토어) 2010-01-01 10:59:25
iPodTouch가 한대 더 생겨서 Bluetooth 메신저 디버깅을 대충 끝내다.(아이폰 앱 블루투스 앱스토어) 2010-01-06 17:15:05

이 글은 공중곡예사님의 2009년 12월 17일에서 2010년 1월 6일까지의 미투데이 내용입니다.

최근에 하고 있는 짓들이란게 이런거라는...ㅎㅎ
그래서 글도 잘 못쓰고 있습니다.
이 블로그에 가끔 들러주는 분들께 죄송할 따름...

다들 눈 많이 내리는 한겨울에 별 탈 없이 지내고 계신지...

저는 보시다시피 당분간은 아이폰 응용 개발이나
논문 작성 때문에 바쁠 예정이라 블로그에는 좀 소홀할 듯 싶습니다.

이 한 겨울에 다들 건강 조심하시고...

이런 식으로라도 가끔 글 남기도록 하겠습니다.

아이팟 터치가 두대가 생겨서 그래도 할 수 있는 것들이 좀 늘어나 즐겁네요.

대박까진 몰라도 뭔가 새로운 것들을 배울 수 있는 기회가 되었으면 좋겠습니다.
새로운 것을 배운다는 것은 언제나 즐거운 일이니까요.

(그래도 Objective-C에는 친숙해지기가 너무나 어렵군요. ㅎㅎ)

논문은 Consistent Hashing을 활용한 failover system 구현에 관한 것입니다.
잘 될지는 모르겠지만... 2월이 마감이라 이번 한달 동안은 꽤나 바쁠 것 같군요.
이제 실험도 착수해야하고... 논문도 고쳐야 하니까요.

사실 실험에는 젬병인데...
어떻게 해야 할지 고민도 많이 되는군요.

나이들어 박사학위 과정에 계속 머물러 있는 것도 부담이라
이번에는 어떻게든 끝내야 할텐데....

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Objective-C에서의 클래스 변수

이병준 — Wed, 30 Dec 2009 20:05:51 +0900

Objective-C에서는 클래스 변수의 개념을 명시적으로 지원하지 않습니다. Java 같으면 다음과 같이 할 수 있었겠죠.

public class MyClass {
static int INSTANCE_COUNT = 0;
//...
}

하지만 Objective-C에서는 그렇게 할 수 없기 때문에, static 변수를 사용한 편법을 써야 합니다. C/C++에서 static 키워드는 다음과 같은 효과를 갖습니다.

1. 함수 안에서 static으로 선언된 변수의 lifetime은 그 함수가 최초로 사용된 시점부터 프로그램이 종료될 때 까지로 연장된다.

2. 함수 외부에서 static으로 선언된 변수의 scope는 그 변수가 사용된 파일 내부로 한정된다.

따라서 2번 규칙을 사용하면 비슷한 효과를 얻을 수 있습니다.

다음 예제를 한번 보시죠.

// MyClass.h

@interface MyClass : NSObject {
}

+ (MyClass*) myClassFactory;

+ (int) count;

- (id) init;

@end

// MyClass.m

@implementation MyClass

static int INSTANCE_COUNT = 0;

+ (MyClass*) myClassFactory {
++INSTANCE_COUNT;
return [[[MyClass alloc] init] autorelease];
}

+ (int) count {
return INSTANCE_COUNT;
}

- (id) init {
if ( self = [super init] ) {
// ...
}
return self;
}

@end

- - -

삽질의 길은 언제나 멀고도 험하다는...

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Ready for Sale

이병준 — Thu, 24 Dec 2009 10:01:44 +0900

심심해서 만들어봤다던 아이폰 앱 10000 hours가 앱스토어에 등록되었다. 링크는 http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=347168390&mt=8 이다. 소프트웨어가 허접해서 리뷰가 빨리 끝난듯.. -_-;

가만 보고 있으니 어서 빨리 업데이트나 해야 겠다는 생각이 밀려든다. 그런데 벌써 두 번째 소프트웨어 "CoffeeBreak"를 만들고 있는 상태라 그거 끝날때까지는 아마도 첫 번째 소프트웨어의 다음 버전은 내놓지 못할 듯...

아이디어는 좀 있는데 시장조사할 여력도 없고 UI 구현도 하도 오랫만에 해보는 거라 진도가 더디다. 취미삼아 시작한 건데 이러다가 중독되는 건 아닌지...

"CoffeeBreak" 이야기하니까 아침부터 커피가 무지 땡긴다. 어제 너무 마셔서 잠을 설쳤는데, 오늘은 적당히 좀 마셔야 할듯... 하지만 앱스토어 등록 자축 의미로 따아악 한잔만!

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

10000 hours - 심심해서 만들어본 아이폰 앱

이병준 — Thu, 17 Dec 2009 14:11:39 +0900

연말이 되었는데 이런 저런 실험 탓에 기다려야 하는 시간이 많아서 시간도 때울 겸(?) 아이폰 앱을 하나 만들어 보았다. "아웃라이어"에 보면 10,000시간의 법칙이 나오는데, 요지는 10,000시간의 의도적 수련(deliberate practice)이 전문가를 만들어 준다는 것이다. 이 시간을 관리할 수 있게 하는 앱이다. (이런 거나 하고 있으니 한가해 보이는 걸까...)

As pointed out in the book "Outliers", a professional is made by 10,000 hours deliberate practice. This iPhone app manages time spent on your deliberate practices.

First, you define "Areas" where you want to be a professional.

Next, you define "activities" which comprise an area. The time spent on each activity is summed and displayed in the area view page.

By clicking activity and press "Start" button, you can count the time spent on the acvitivity. Following screen shows that I've spent 8 minutes on 'coding' activity :-)

To stop the counting, you can press "stop" button or "back" button at the top of the screen. That's it.

개인적인 용도로 써먹을려고 만들었는데, 시험삼아 공개해보는 것도 나쁘지 않을 것 같아서 앱 스토어에 등록을 신청해 둔 상태다. 어제 먹은 술이 덜 깨서 등록 절차를 제대로 밟았는지도 잘 모르겠다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Programming in Objective-C 2.0

이병준 — Wed, 16 Dec 2009 06:42:20 +0900

얼마전에 Programming in Objective-C 2.0을 받았다. 아이폰 어플을 개발해보려고 하던 차라, 마침 필요하던 책이었다.

Objective-C를 입문할 때 C++이나 Java 프로그래머가 가장 헷갈리는 부분을 꼽으라면?

1. 메모리 관리 (retain, copy, release, autorelease...)
2. [와 ]로 표현되는, 다소 생뚱맞은 메시지 전달 방식
3. C++과는 달리, 대충 대충 해도 일단은 넘어가주는 클래스 선언 방식

C++이나 Java 프로그래머에게 있어서 Objective-C의 진입장벽은 다소 낮은 편이다. 뭐 어차피 다 같은 객체지향 언어이므로, 사실 거기서 거기다. 그러니 저런 부분만 파악하면 쉽게 쉽게 코딩을 할 수 있지 않을까 생각해서 애플에서 제공하는 Objective-C 2.0 가이드를 대충 본 다음에 바로 코딩에 들어갔었다.

그런데 아니나 다를까... 역시 대충 대충 공부한 탓인지 결정적인 부분에 가면 꼭 막혔다. -_-;

- - -

C++을 한 8년 가까이 한 이후, Java The Programming Language를 한 일주일 정도 보고 나서 바로 Java 프로그래밍을 할 수 있었다. 객체지향 언어라는 것에 대해 익숙해진 탓도 있었겠지만, 책이 워낙 잘 씌여진 탓도 있었다. 좋은 교과서가 있으면 실패할 확률이 줄어든다.

Objective-C의 실질적인 교과서를 꼽으라면, 이 책일 것이다. 크게는 2부로 나뉘어 있다. 언어적인 특성을 설명한 1부. 그리고 C++의 STL에 해당하는 Foundation Framework에 대해서 설명한 2부.

다른 프로그래밍 언어 서적들과 크게 다른 구성을 가지고 있지 않고, Java나 C++과의 차이점을 비교설명하고 있지 않으므로 그런 부분만을 재빨리 파악한 다음에 바로 프로그래밍을 시작하려는 사람에게는 그다지 적당하지는 않다. 하지만 책이 평이하고 쉬운 어조로 서술되어 있으므로, 일주일 정도 투자하면 완독할 수 있을 것이라고 생각한다.

정 시간이 없는 사람은 부록 B만 읽고 넘어가도 된다. -_-; 언어를 전반적으로 요약해두었으니 Objective-C에 대한 기본적인 사항을 이미 알고 있는 사람이라면 그래도 될 것이다.

그러나 아쉬운점은, 부록 B에 적힌 내용을 좀 더 자세히 알고 싶을 경우 본문의 어디를 보아야 하는지를 전혀 알 수가 없다는 점이다. (C++ The Programming Language의 경우, 관련된 부분에 대한 링크가 일일이 달려 있는 것과는 대조적이다.) 가령, property를 사용할 경우 retain, copy 등의 속성을 property를 선언할 때 지정해 주게 되고 이것이 메모리 관리와 연관이 있다는 내용이 부록 B에는 친절하게 정리되어 있는데, 이게 메모리 관리와 실질적으로 어떤 관계를 맺고 있는지를 파악하려면 어디를 보아야 하는지 알 수가 없다. 목차를 보면 17장 "메모리 관리"를 보면 되겠구나 싶겠지만, 아니다. 관련된 부분은 책 여기 저기에 흩어져 있다. (가령 nonatomic과 copy에 대한 내용은 482페이지에 가서야 설명된다.)

그런 사소한 불편함을 빼면, Objective-C를 공부하는 사람은 가지고 있어야 할 책이라고 생각한다. 객체지향 언어에 이미 익숙한 사람에게는 설명이 너무 많아 장황하게 느껴질 수도 있겠지만, 나처럼 나중에 개고생하지 않으려면 이런 책을 꼼꼼하게 읽어두는 것이 좋다. 원래 교과서라는 게 다 처음에는 재미가 없다. -_-;

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.