64K Stack Memory

  열혈 버닝중이라, 점점 포스팅이 늦어지네요.

 

요 몇일(실은 하루 -_-) 프로그램이 아주 깔끔하게 죽는 버그가 있었습니다.

 

아주 깔끔하게 아무런 흔적도 없이 사라져버리는군요.

 

결국 이유는 위의 64K Stack Memory 때문입니다.

 

윈도우와 윈도우 모바일의 차이중에 하나가, 윈도우 스택은 1M 입니다.

 

그런데 윈도우 모바일은 모바일이다 보니, 64K 입니다. 물론 per thread 기반입니다.

 

윈도우 개발하던 사람이 윈모로 오다보면 젤 실수하기 쉬운 부분이 그렇습니다.

 

살짝 리커즌 도는 함수안에 TCHAR path[4096] 이런거 있습니다. 곧 죽습니다. -_- 

 

NSUnknownKeyException

IPhone 책의 예제를 따라하다가, 위의 에러가 나면서 자꾸 프로그램이 죽는 현상이 발생했다. 해당 에러가 먼지도 모르고 계속 보고 있다가(사실 처음에는 위의 에러인지도 몰랐다. 손버깅 할려다가 GDB로 보니 위의 메시지가 휘리링~~~)

아무리해도 고쳐지지가 않고, 책과 예제가 전혀 차이가 나는 부분이 없는데, 무엇이 문제일까 하다가 결국 .xib 파일이 문제라는 것을 알게 되었다.

코코아 프로그래밍의 경우, xib 를 이용하여 쉽게 프로그래밍을 할 수 있는데, 그 제약 사항이 많아서 보통은 .xib 를 쓰지 않는 형태로 코드를 작성하게 된다. 그런데 이 경우 –_-, .xib 에 기본 셋팅 정보가 들어있어서 이걸 지우지 않고 그냥 쓰게 되면, 해당 설정 정보와 현재 프로그램의 실행정보가 맞지 않아서 에러가 발생한다.

결국 가볍게 지워주니 한시간 넘게 삽질한 결과가 허무하게 잘 나온다.

이런 T.T 삽질의 황제가 되버렸군 T.T

Continuous Integration

Continuous Integration(이하 CI) – 지속적인 통합이라는 의미다.

요새 꽤나 “이슈” 가 많이 되고 있는(사실은 좀 이전에~~~) 주제이기도 하다.

 

보통 CI 라고 하면, CI 툴을 사용해서 설치하면 되지 않는가 라고 생각하기 쉽다.

사실 이 말도 맞다. 하지만, 모든 것이 그렇듯이 CI의 핵심은 “사람” 이고 “팀원” 이다.

 

먼저 CI의 구성 요소를 살펴보자.

1. 소스 형상 관리 시스템( SVN, CVS, VSS 등등 뭐든지 좋다. )

– 소스 형상 관리 시스템이 없다면,  솔직히 CI가 구성되지 않는다. 상상해보자.

특정 시간마다, 수많은 사람들이 USB나, 이메일 등 을 통해서 서로 다른 소스를 던져준다면?

수많은 버그와 함께, 코드 되돌리기 신공이 난무하게 될 것이다.  SVN을 쓰더라도 머지가 힘들 수도

있지만 (사실 SVN 등을 쓸 때, 머지의 책임은 뒤에 커밋하는 사람이 지는 것이다. ) 과연 어느 것이

쉬울지는 잠시만 적응해 보면 안다.

 

2. 빌드 머신 과 한방 빌드

보통 빌드라는 건, 개발자가 자신의 로컬 머신에서 VS등에서 F7 등을 눌리면 되는 것으로 생각하기 쉽다. 그러나, 빌드라는 것도, 공식 빌드, QA 빌드, 개발자 테스트 빌드, 개발도중의 빌드 등으로 나눌 수 있다. 여기서 개발 도중에 개발자가 하는 빌드를 빼고는 개발자 테스트 빌드 조차도 한방 빌드라는 공식화된 빌드 루틴을 타야 한다.

한방 빌드라는 것은, 그냥 배치 스크립트 등을 딱 한번 누르면, 깨끗한 머신에서 알아서 소스코드를 가져오고, 필요한 라이브러리를 링크해서 빌드 결과를 알려줄 수 있는 시스템이다. 그 안에는 사람의 손이 추가로 가서는 안 된다.

일일 빌드라는 유명한 것도, 이 한방 빌드로 만들어져야 한다.

3. CI 툴

사실 CI 툴은 편의를 도와주는 것이지만 사용하기 힘들다면 꼭 안써도 된다. 그냥 2의 한방 빌드를 예약 작업으로 걸어놓고, 10분이나, 1시간 단위로 돌려서 결과를 확인해도 된다. 하지만, 편의를 도와준다는 것은 생산성을 향상시켜준다는 것을 알아야 한다.

4. 사람(별표 백만개)

위의 시스템이 잘 갖춰져 있어도, 쓰는 사람들에 따라서 천지 차이다. –_-

SVN이 있더라도 하루에 한번 체크인을 한다든지, 3개월에 한번 한다든지 한다면, 별 의미가 없다.

같은 한방 빌드라도, 필요한 부분을 빨리 체크해서 결과를 알려주는 것과, 모두 끝난뒤에야 결과를 알려주는 등의 것도 어떻게 구성하는지에 따라서 매우 결과가 달라진다.

CI툴의 리포트도 사람이 신경쓰지 않으면 전혀 의미가 없다.

그래서 결국 사람이 가장 중요하다.

위에 것들이 관심이 있다면, 최소 1,2번 까지라도 설정해 보길 바란다.

CI 툴중에 소스코드를 커밋한걸 감지하고 있다가 소스코드가 커밋될 때마다 빌드해서 알려주는

기능도 있으니, 누군가 커밋을 빼 먹어 생기는 문제가 많다면, 이런 기능을 이용해 보는것도 어떨까?

애자일 시리즈 – 애자일 회고

  인사이트에서 나온 애자일 시리즈

 

스크럼과 XP(가장 최근에 나온)

스크럼(같은 스터디 멤버인 일이형이 번역한…)

익스트림 프로그래밍

애자일 회고(가장 많은 도움이 되었던)

불확실성과 화해하는 프로젝트 추정과 계획(나는 아직도 추정과 계획에 서투르다.)

사용자스토리

애자일 프랙티스

린소프트웨어(도요타 방식을 린 프로세스라고 한다.)

 

 위의 책들 중에서 내가 구입한 책은

스크럼(안 살수가 없다 ㅋㅋ, 번역자랑 아는 사이니 T.T)

애자일 회고( 개인적으로 회고라는 개념이 매우 중요하다라는 것을 이 책을 보고 나서야 깨닫게 되었다.

 그리고, 무엇을 하든지, 회고를 적용하는 것이 장점이 많다는 것도 느꼈다.)

불확실성과 화해하는 프로젝트 추정과 계획(사고나서 아직 제대로 읽지 못한 책 T.T

 일정에 대한 추정과 계획은 아직도 어림짐작이다. T.T – 이번 스터디 부교재 T.T)

사용자 스토리( 일을 어떠한 단위로 나눌것인지, 이번 스터디 부교재이기도 하다. T.T)

 

다들 좋은 책이긴 한데, 개인적으로 가장 도움이 된 책은 애자일 회고 였다.

처음에 나는 “회고”라는 말이 무엇인지 몰랐다. -_-,

 

회고를 사전에서 찾아보면

 

회고 [回顧] [명사]
1 뒤를 돌아다봄.
2 지나간 일을 돌이켜 생각함.

 

 위와 같은 설명이 나온다. 즉, 어떤 일을 하고 나서, 무엇이 좋았는지, 무엇이 나뻤는지에 대해서

생각하고, 더 나은 방법을 찾는 것이다. 혼자서 하는 일에 적용할 수도 있고, 여러명이 하는 일에

적용할 수도 있다.

 

 그리고 중요한 것은 회고도, 준비가 필요하다는 것이다.

• 사전 준비
• 자료모으기
• 통찰 이끌어내기
• 무엇을 할지 결정하기
• 회고 끝내기
• 새로운 시도와 개선을 결정하기

 

위와 같은 순서가, 애자일 방법의 이터레이션과 합쳐지면서

매 이터레이션의 끝마다 회고를 적용할 수 있고, 해당 프로젝트가 끝나거나 릴리즈를 할때마다도

회고가 연결되어서 실행될 수 있다.

 

 슬램덩크의 안감독님이 말씀하신 명대사 “초보자의 상급자로 가는 길은 자기가 서툴다는것을 알았을때가 시작이다” 처럼, 가장 먼저 해야할 것은, 무엇을 잘못하고 무엇을 잘아는지 아는것이 가장 먼저이다.

애자일 회고는 그런 부분에 대해서 그 시작 점을 잡아주는 역할을 할 것이라고 생각한다.