'Project'에 해당되는 글 41건

  1. 2013.05.26 합격하는 이력서의 공통점?
  2. 2013.05.17 DeNA 개발자 주최 아이폰 개발자 스터디?
  3. 2012.10.17 Coredata Background 처리에 관하여
  4. 2012.04.15 PHP 단상
  5. 2012.04.13 JSON data로부터 간단히 모델 클래스를 구현하기
  6. 2011.12.05 서버개발자 그리고 아이폰 개발자
  7. 2009.07.01 소프트웨어에서의 추상화 그리고 상속,다형성,캡슐화 (1)
  8. 2009.06.25 정말 다형성(서브타입)이 IF를 줄일수 있을까? (8)
  9. 2009.04.25 객체 지향과 절차지향 단상. (2)
  10. 2009.04.22 프로그래밍을 하면서 수학과 포인터가 필수인가요? (4)

합격하는 이력서의 공통점?

Project 2013.05.26 14:05

최근 우리 회사에 입사하려는 사람들의 이력서를 검토하게 되었다.

이력서를 읽고 합격하는 사람들의 공통점을 간단하게 정리해봤다.


이력서


1. 쓸수 있는 기술을 가진 사람이 중요.

경력자를 뽑는 기준은 단순하다. 즉시 전력이 될수 있을만한 기술 및 경험을 가지고 있는 사람이다. 

보통 회사 구인공고란에서 요건(Requirements)부분에 맞는 사람이 서류심사에 유리한 조건을 가지게되고

책무(responsibilities)부분을 면접때 확인하게 된다.




2. 쓸수있는 기술중에 깊이 있는 기술의 이해와 트러블 슈팅 가능한 사람이 중요. (플랫폼지식)

사실 업무에 적응해서 일하는것은 보통의 엔지니어(?)라면 누구나 다 할수있고 라이브러리가져다 사용하는것 또한 누구나 할수 있는일이다. 이런 구인 공고를 통해 찾는 엔지니어는 쓰고있는 기술의 하부까지 깊이 이해하고 트러블슈팅까지 가능한 엔지니어를 찾는다.(같은 이야기이지만) 이런 엔지니어는 드물지만 지원자에 있으면 서류는 볼필요없이 바로 통과.

자신이 어디에 서 있는지 그 바닥을 알고 있다는 것은 중요하다. 




3. 특별,특이한 이력은 주목을 받는다.

이력서중에 독자적인 기술이나 경력이 있다면 주목을 끌수있다.

예를들면 유명한 프로젝트의 개발이력이라든지 , 수상이력이라든지 , 특별한 기술이라든지 등등등.. 

 


4. 모르는 기술이 있으면 흥미를 끈다.

역시나 이력서를 보는것은 엔지니어, 자신이 모르는 기술이나 용어가 나오면 흥미를 끌게된다.

같은 이력서라도 한번더 읽어보게 만든다.

 


5. 트러블 슈팅내용이 흥미롭다. 해결방법이 궁금해지는 내용

경험한 트러블이 흥미롭고 , 해결방법 또한 정확하다면 흥미가 가게된다.

 


6. 프로젝트내의 역활에서 개발 리더,메니져경험이 있으면 +

회사내에서 리더나  메니져의 경험은 중요. 특히나 덕후들이 많은 개발회사에서는 가산점이 된다.


7. 프로젝트의 규모, 프로그램의 처리능력,등 수치적인 데이터가 있으면 +

일단 숫자가 나온다는것은 지원자의 성격이 분석적이라는 이야기이다. 이 바닥에서 숫자의 의미는 대단히 중요.

또 어떤 규모의 프로젝트를 경험했는지도 참고가 된다.

 


8. 프로젝트 이력에서 자신이 맡은 프로젝트의 전체적인 모습을 파악할수 있으면 +

보통 프로젝트내에서 자기가 맡은 모듈밖에 알지 못하는 경우가 많다.

하지만 일부분만을 담당했더라도 전체적인 모습을 파악하고 있다면 가산점이된다. 


9. 자기소개에서 필요한것은 자신의 소개가아닌 자신의 강점이다.

난 자기소개서를 쓰는 이유가 이해안되는 1인이지만. 어딜가나 한국과 일본에서는 (아마 중국도?)

자기소개를 써야하는란은 항상 있다.

 보통 내용도 자기 가족관계라든지 , 어린시절의 경험들이 써있는데 사실 자기소개에서 중요한것은

자신의 인생에서 자신의 강점을 어떻게 잘 설명하는가이다. 


10. 자기소개에서 리더쉽,리더,개발관련 경험이 있으면 +

위와 이어져서 기술지향,리더쉽,커뮤니케이션능력등을 잘 어필하면 가산점이 된다.

개인적으로 개발을 한다던지, 개인 프로젝트가 있다던지, github에서 오픈소스를 개발했다던지 등등등..



11. 입사후 미래, 회사의 위치,자신의 역활,방향 구체적이며 회사와 맞으면 +

 미래라든지 자신의 위치라든지 이런건 개인적으로 별 의미없는 질문이라고 생각하지만, 회사가 생각하는 인재상과 맞으면 가산점이 된다.



면접 감상


1. 커뮤니케이션 능력은 중요

면접에서 많이 보는것은 이력서의 내용이외에, 커뮤니케이션 능력을 본다.

같이 일할 사람으로서 함께 일할만한 사람인지를 많이 보기때문에 커뮤니케이션 힘들면 어렵다.



2. 질문에 대한 이해도와 답변의 신뢰도또한 중요

위와 연결되는데 두번말해야 알아듣거나 , 답변의 자신이없고 틀리면 어렵다.



3. 쉽게 설명하는 능력

이것도 1번과 연결되는데 하고싶은 이야기를 쉽게 설명하는것도 많은 가산점이된다.

 


4. 태도

 특별히 눈에띄는 행동을 하지 않으면 괜찮다. 필요이상으로 오버하지만 않으면 된다.

너무 오만하다던가, 예의가 없어보이는 행동을 하지 않으면 된다. 


5. 의욕

 태도와 연결되는데 우리회사에서 함께 일하고 싶은 의욕이 보이지않는다면 그것도 마이너스.



 단 말하지 않은것이 부분은 이 모든 것도 기술력이 갖춰진상태여야 자격이 주어진다는것이다.

역시 기술을 키워야...

 

Trackback 0 : Comment 0

DeNA 개발자 주최 아이폰 개발자 스터디?

Project 2013.05.17 00:15

 정말 바쁜 일정인 와중에 같은 건물 다른층에 입주해있는 타회사 엔지니어가 주최하는 아이폰 개발 스터디가 있다고 하길래 잠깐 참가를 해보았다.


 먼저 주최자 소개 


 Mathda Matho?

이전 우리회사에 다니다가 전직하여 DeNA로 가버렸지만 그때 유지하던 스터디를 DeNA로 까지 끌고가서 아직도 운영하고있다.

사실 이번 스터디도 처음은 이전 회사에 친하던 엔지니어가 부추겨서 시작한 스터디였지만 그 친구분은 다른곳으로 이직을 하고 혼자서 이끌어나가고 있는 상황인듯 

그분의 홈페이지 http://yuez.net/  

개인적으로 3명의 다른 팀멤버와 elleReader를 개발하였다고 한다.


이외에도 다른 참가자들도 각각 아이폰 개발자 또는 흥미를 가진사람이 많이 있었는데 몇명 소개를 하자면

오오무라상 20대 초반 , 이전 우리회사에 UX팀에 있다가 KONAMI로 전직하였지만 아이폰 개발에 흥미가 있어서 참가.

신입때 한번 대화를 나눈기억이 있는데 꽤나 활발하고 의욕이 넘치는 분이었던걸로 기억. (그분도 나를 기억하고있었다.)

WWDC에 참가한다고한다. 전액 전액(티켓,숙박,비행기) 회사부담이란 이야기를 듣고 부러움을 한눈에..


Exite Japan출신 엔지니어 두분, 오늘 출시를 발표한 Dモーニング ( 주간 만화 잡지의 스마트폰 앱 ) 의 개발하신분이다. 

관련기사 http://ebook.itmedia.co.jp/ebook/articles/1305/16/news016.html


모 인터넷기업의 CTO겸 사장분. 취미로 아이폰 개발을 하시는듯.


나머지 분들도 다들 github 계정으로 오픈소스개발을 취미로하시는분들이었고, 기술력도 어느정도 되시는 사람들밖에 없었다.


오늘 발표중 재미있었던점은 주최자가 개발한앱에 관한 이야기였는데 정리하면

- elleReader의 액티브 유저는 5000명수준

- 5000명정도로는 무료앱 70-140위를 왔다갔다하는듯

- 광고수익이 매월 3만엔-5만엔이상 들어옴

- 비슷한 다운로드수의 지인 엔지니어의 앱은 그정도까지 광고수익이 안난다고 함. 아마 원인은 변화하는 콘텐츠때문이 아닐까라고.

- 기본 구조는 , 클라이언트 <-> 빈약한 콘텐츠 서버(월200엔) <-> google reader api를 이용해 데이터를 크롤 및 검색 

인데 이번7월에 google reader가 종료를 하기때문에 다른 api를 찾고있다고 한다, 만약 못찾으면 앱을 내려야할판(모두 웃음ㅎㅎ)


나머지는 github에 공개되어있는 자신들의 소스코드들을 보여주고 설명해주는 선에서 마무리가 되었다.


이 스터디에 참가해서 느낀점을 정리하자면


- DeNA 사내 카페는 참 고급스럽고 좋다

- 좋은 개발자는 역시 다들 취미로 코딩을 하는듯(github등)

- 이미 팀을 꾸려서 결과물을 만들어 내는 사람들도 많이 있구나. 굉장히 자극을 받았다.

- 새로운(유능한) 사람들을 만난다는것은 역시 좋은 자극을 받는듯.


바다로 시작하는 모님이 긴글을 쓰기 시작하는걸보고 나도 자극을 받아 긴글을 써보기로 마음을 먹었다.

지금은 너무 오랜만의 글이라 두서없고 횡설수설한 느낌이 있지만
예전의 4년-5년전의 나와 어떤 다른글을 써낼수 있을지 자기자신도 기대된다.





Trackback 0 : Comment 0

Coredata Background 처리에 관하여

Project 2012.10.17 22:43

격주 릴리즈의 바쁜 스케쥴안에서 시간을 쪼개 코어 데이터 처리 로직을 백그라운드에서 처리하려는 작업을 조금씩 진행시켜 이번버젼에야 겨우 적용할수 있었다. 여기에 약 6개월간에 걸쳐 내가 겪은 시행착오에 관한 기록을 남긴다.

1. 기존설계의 문제점

  모든 처리를 MainThread에서 하도록 구현되어있었기 때문에 화면이 멈추는 경우가 자주 있었다.
Main Thread에서 처리하지 않으면 안되었던 이유는 UI의 변경은 반드시 Main Thread에서 하지 않으면 안되기때문이다.


모든 작업을 main Thread에서 처리하더라도 발생하는 한가지 이슈가 있었는데,

비동기 리퀘스트(Asynchronous Request)와 Block을 이용할때 request시에 취득한 NSManagedObject는 respoonse때에 다시 사용할경우 문제가 생길 가능성이 있다.

ex)

a. Request - A 유저 데이터를 이용하여 request를 보냄
b. A 유저데이터가 삭제됨
c. Response - A 유저 데이터를 그대로 이용하여 작업 하지만 이미 삭제되어있기때문에 fault된상태이기때문에
crash 를 유발할수있다.

이때문에 response블록에서는 사용될 데이터는 moc로부터 새로 취득하여 사용하지 않으면 안되었었다.



2. 개선 - 2개의 NSManagedObjectContext

 기동시에 데이터를 정기적으로 체크하지 않으면 안되는 로직이 있어서 해당 작업을 배치로 묶어서 백그라운드에서 처
리하도록 수정하였다.
 수정방법은 배치에 사용될 NSManagedObjectContext(이하 MOC)는 직접 DB(persistent)로부터 취득하여 생성하여
main thread사용중인 moc에 영향이 가지않도록 하였다.

 이 작업을 진행하며 발견된 이슈가 있는데

- Fetch Result Controller(이하 FRC)의 델리게이션은 Main Thread에서 일어나야한다(UI)
FRC델리게이션으로인해 table view의 갱신이 일어나게되고 이 작업은 항상 main thread에서 실행되어야만 하는 문제가 있었다.

하지만 데이터의 저장타이밍(moc save)에 FRC에 대한 델리게이션이 일어나기때문에 save타이밍에
직접 merge를 구현하여 main thread에서 실행되도록 수정하였다.

save시에 notification(NSManagedObjectContextDidSaveNotification)을 observer하여
MainThread에서 noti데이터로부터 main context에 merge하도록 수정하였다

....

            [[NSNotificationCenter defaultCenter] addObserver:moc selector:@selector(merge:) name:NSManagedObjectContextDidSaveNotification object:moc];
....

- (void)merge:(NSNotification *)notification

{

......

    dispatch_async(dispatch_get_main_queue(), ^{

        [mainManagedObjectContext mergeChangesFromContextDidSaveNotification:notification];

    });

....



3. 개선 - 2개의 Context 그리고 GCD QUEUE

모든 데이터의 처리는 아래의 2개의 context를 이용하여 데이터를 처리하기로 결정하엿다.

a. Read 및 UI용 Main Context
FRC에 설정되거나, viewDidLoad시에 사용될 데이터을 위해서만 사용된다.
이 MOC에대한 수정 및 Save는 금지된다.

b. 데이터 수정용 private context
수정이 필요한 NSManagedObject들은 이 MOC로부터 취득한다.
UI에서는 절대 사용하지 않도록한다.

위의 콘텍스트를 두가지로 나눈이유는 merge conflict 머지경합을 방지하기 위해서이고
기본 비지니스로직의 처리는 private MOC의 performBlock 안에서 하도록 강제한다.

만약 로직에 UI변경이 필요하다면 

dispatch_sync(dispatch_get_main_queue(), ^{ UI 변경 });

을 이용하여 처리하도록 한다.

 이렇게 함으로서 자연적으로 처리가 비동기, 백그라운드에서 실행하게 되며 기본적으로 UI작업과 독립적으로 이루어지기 때문에 앱이 멈추는 경우는 거의 사라졌다.

이 작업을 진행하면서 발견한 몇가지 이슈가 있는데 

-  MOC의 생성과 사용은 항상 같은 Thread이어야만 한다.
GCD queue를 이용해 block을 dispatch 했을경우, block내의 moc가 다른 thread에서 실행될경우에 데이터가 엉키거나 크래쉬되는 문제가 있었다.

 쉽게설명하면 
GCD Private Queue

BLOCK 1
{
   MOC A를 생성
} Thread A에서 실행

BLOCK 2
{
  MOC A를 가지고 작업
} Thead B에서 실행

Private Queue이기때문에 기본 시리얼하게 실행되겠지만 , moc가 생성된 thread가 아닐경우 문제가 생길 가능성이 있다.


- IOS4의 MOC에는 perform block이 존재하지 않는다.

IOS5에서 추가된 기능중하나는 GCD Queue를 이용한 core data 처리관련 기능들이 추가되었다는것이다.
NSManagedObjectContext 를 생성할때 ConcurrencyType를 지정할수가 있다.

NSPrivateQueueConcurrencyType
 이 타입으로 생성한 MOC는 performBlock을통해 실행되어 사용된다면 특별히 신경쓰지 않아도 thread safe가 보장된다.

NSMainQueueConcurrencyType
 performBlock내의 처리로직들은 항상 main thread에서 실행된다.



IOS5에서는 private context를 NSPrivateQueueConcurrencyType으로 생성하여 block내에서 실행한다면 쉽게 백그라운트 처리가 가능해졌다.

하지만 문제는 IOS4 , IOS4를 위해서 직접performBlock을 구현하고 private thread를 생성하여 해당 block의 실행을
동일한 thread로 강제하였다.

ex

        privateQueueContextThread_ = [NSThread newDefaultModeRunLoopThread];

        [privateQueueContextThread_ performBlockAndWait:^{

            privateQueueContext_ = [[NSManagedObjectContext alloc] init];

        }];



직접 prvateQueueContext의 초기화를 privateQueueContextThread에서 실행하고

    @autoreleasepool {

        if (NO == [NSManagedObjectContext instancesRespondToSelector:@selector(performBlock:)]) {

            __unsafe_unretained Class mocClass = [NSManagedObjectContext class];

            IMP performBlockIMP = class_getMethodImplementation(mocClass, @selector(iOS4PerformBlock:));

            IMP performBlockAndWaitIMP = class_getMethodImplementation(mocClass, @selector(iOS4PerformBlockAndWait:));

            

            class_addMethod([NSManagedObjectContext class], @selector(performBlock:), performBlockIMP, "v@:@?");

            class_addMethod([NSManagedObjectContext class], @selector(performBlockAndWait:), performBlockAndWaitIMP, "v@:@?");

        }

    }

performBlock을  구현하였다.

- (void)iOS4PerformBlock:(dispatch_block_t)block
{
  [privateQueueContextThread performBlock:block]


이로서 ios4,ios5에서도 동일한 코드로서 백그라운드 처리가 가능하게되었다.

4. Etc 몇가지 팁

- 비동기로 처리시 UI작업에서 사용하기전에 삭제된 NSManagedObject가 아닌지 체크하여라

- (BOOL)wasDeleted

{

    id myObject = [self.managedObjectContext existingObjectWithID:[self objectID] error:NULL];

    return myObject == nil;

}


위의 함수를 NSManagedObject의 category로 등록하여 , 사용전에 wasDeleted로 체크한다면
릴리즈 데이터의 엑세스로인한 crash이슈는 막을수 있을것이다. 



- Core data에서 sqlite 의 데이터중 name값이 NULL값을 찾고싶을때?

[NSPredicate predicateWithFormat:@"name = NULL"]


5. 마지막으로

 사실 위의 코드로 실제 백그라운드를 바로 구현하기는 어렵겠지만, 문제의 원인과 수정에 대한 방향은
잡을수 있으리라 생각된다.


p.s 이 슬라이드에서 내가 한 방법과 완전히 같은 방식으로 멀티쓰레드 코어데이터를 구현했다. (11월10일)
http://www.slideshare.net/Inferis/adventures-in-multithreaded-core-data


Trackback 0 : Comment 0

PHP 단상

Project 2012.04.15 23:30

PHP: 잘못된 디자인의 프랙탈 


PHP를 정말로 증오하는 분이 쓴 글을 국내의 블로거가 번역한글인데 , 최근에 읽은 블로그 중 가장 재미있어서 나도 PHP의 단상을 몇가지 적어본다.

 먼저 나또한 위의 글을 전적으로 동의한다. PHP개발을 하며 나타나는 알수없는 버그들등에 고생을 한 경험이 있어서 PHP가 얼마나 거지같은지 깊이 공감을 한다.
 하지만 왜 언어 랭킹을 보면 항상 저자가 좋아하는 Python보다 높은 순위에 있으며 , 그 인기가 10년가까이 지속되고 있는지 생각해볼필요는 있을것같다.

1. PHP는 왜 그렇게 많이 쓰이는가?

- 먼저 PHP는 환경설정이 정말 간단하다.
윈도우라면 XAMP , 맥이라면 MAMP , 리눅스라면 LAMP 로 검색해서 나오는 패키지를 인스톨하면 끝이다.
다른 환경설정 필요없이 그냥 설치하고 htdocs에 php를 넣어두기만 하면 끝이다.
물론 실제 서비스때는 apache,php설정등을 바꿔줘야하지만 다른 언어에서 그것에 비하면 정말 생각할것이 없다.

- 빠른 개발속도
당신이 프레임워크를 이용하든, 그냥 통짜 php로 개발을 하든 무엇을 이용하든 익숙한 개발방법이 있다면 하나의 화면을 구현하는데 정말 별로 시간이 걸리지 않는다. 내 경험상 자바로 개발할때보다 4배이상은 빠르게 개발할수 있다고 말할수 있다.

- 낮은 학습곡선
PHP는 정말 누구나(개나소나) 쉽게 배울수 있다.
귀찮은 부분은 다빼버린 언어 설계때문에 (그로인해 심각한 결함들도 있지만) 그냥 생각한대로
쓰면 왠만하면 결과가 나온다.
또 PHP프레임워크는 배우기가 정말 쉽기 때문에 다른언어의 프레임워크보다 쉽게 이용할수가 있다.
(어려우면 안쓴다)

- 풍부한 라이브러리
게시판,블로그,홈쇼핑등의 많은 레퍼런스및 오픈소스가 있으며 필요한 함수나 소스코드는 검색만 하면 나올정도로
도처에 널려있다.(C&P가 많아서 문제,중복되는 기능의 함수가 많아서 문제이긴 하지만)

2. 그리고 현실적인 이유들

- 개발자를 구하기 쉽다.
학습곡선이 낮은만큼 PHP개발자는 도처에 널려있다.
컴퓨터 전공이 아닌 많은사람들이 웹페이지를 만드려고 처음 개발을 시작해서 접하는것이 html 다음이 php이기에
정말 많은 사람들이 php를 알고있다.(커뮤니티의 수준이 낮다고 하는것도 비슷한것이 원인)

- 대부분의 웹사이트들은 규모가 작다
대부분의 웹사이트들은 우리가 생각하는만큼 많은 유저를 대상으로 만들지 않아도 된다.
게다가 개발에 들어가는 돈과 시간도 일주일,100만원수준의 사이트가 대부분.
홈쇼핑에 무회원 계좌이체, 수동결제확인이면 회원관리에 그렇게 보안을 신경쓰지 않아도 되는 경우도 많다.

- 유지보수비용이 상대적으로 적다.
위의 경우와 낮은 학습곡선을 생각한다면 , 대부분의 작은 사이트에서 php소스코드를  수정하는일은 그리 전문적은 지식을 갖지않은 사람도 조금만 공부한다면 할수 있다. (신기능 개발은 무리일지 몰라도)


- 대부분의 PHP개발자는 PHP만 하지 않는다.
PHP만 알아서 먹고살수 있느냐 한다면 대부분의 경우 아니라고 말할수 있다.(JAVA라면 가능)
보통 php개발자는 mysql도 알아야하고 Javascript도 알아야하고, html도알아야하고 css도알아야하고 상황에따라 디자인도해야하는 경우도 많이 있다.이런상황에서 다른언어를 써보라고? 아마 납기 못맞추고 야근하기 쉽상일듯.


3. 결론

내 생각은 앞으로도 PHP의 인기는 계속될것이다. IT업계에서 누구나 항상 좋은 조건의 좋은환경에서 개발할수 있는 것이 아니기 때문에 , 위의 막장처럼 보이는 환경에서 많은사람이 일할것이고 그들은 PHP를 선택해 개발할경우가 많을것으로 보이기 때문이다. (적어도 python보다는)
 
물론 주력언어로 PHP를 쓴다고 한다면 도시락 싸들고 말릴것이다.
PHP를 깊게 파려고하는 당신 왜 이 단순한 언어를 더 공부하려고 하나요?



 
 

Trackback 0 : Comment 0

JSON data로부터 간단히 모델 클래스를 구현하기

Project 2012.04.13 16:30


코어데이터는 데이터를 다루기 위한 굉장히 편리한 도구이지만 데이터의 영속성이 필요하지 않은 경우에는

일부러 코어데이터를 쓰지 않아도 간단히 데이터 모델을 구현할 방법은 많이 있다.


모델클래스를 작성하고 JSON Data로부터 해당 데이터를 바인딩시키는 간단한 코드를 소개한다.

먼저 모델클래스이다.

보다시피 프로퍼티와 초기화 메소드를 하나 지정해둔다.


@interface User : NSObject


@property (nonatomic,strong) NSString *userId;

@property (nonatomic,strong) NSString *userName;

@property (nonatomic,strong) NSNumber *age;

@property (nonatomic,strong) NSString *imagePath;


-(id)initWithDictionary:(NSDictionary *)aDict;


@end

NSObject의 카테고리클래스중 하나인 NSKeyValueCoding은 유용한 메소드를 많이 가지고 있는데

그중 setValuesForKeysWithDictionary: 을 이용하면 dictionary로부터 자동으로 property값들을 세팅할수가 있다.

조심해야할 부분은 이름이 다르거나 가지고 있지 않은 프로퍼티일경우 예외를 내기 때문에

valueForUndefinedKey과 setValue: forUndefinedKey: 를 구현해두어야한다.

#import "User.h"


@implementation User

@synthesize userId,userName,age,imagePath;


-(id)initWithDictionary:(NSDictionary *)aDict

{

    self = [self init];

    if (self != nil) {

        if (aDict) {

            [self setValuesForKeysWithDictionary:aDict];

        }

    }

    return self;

}


- (id)valueForUndefinedKey:(NSString *)key

{

    NSLog(@"undefined key : %@",key);

    return  nil;

}


-(void)setValue:(id)value forUndefinedKey:(NSString *)key

{

    NSLog(@"undefined key : %@",key);

}


-(NSString *)description

{

    NSString *desc = @"";

    for (NSString *key in [PropertyUtil propertyNames:[self class]]) {

        desc = [desc stringByAppendingFormat:@"%@ : %@ ,",key,[self valueForKey:key]];

    }

    return desc;

}


@end

데이터초기화는 아래 한줄이면 된다.

User *user =  [[User alloc] initWithDictionary:jsonValue];



너무 간단한 코드들이라 특별히 이해하는데는 어렵지 않을듯하다.



p.s

직접구현한 모델일경우 프로퍼티내용을 description으로 표시하기가 귀찮을경우가 많은데 아래의 코드를 이용하면 클래스로부터 프로퍼티 이름을 배열로 받을수 있다.

#import <objc/runtime.h>

+ (NSArray *) propertyNames: (Class) class

    NSMutableArray *propertyNames = [[NSMutableArray alloc] init];

    unsigned int propertyCount = 0;

    objc_property_t *properties = class_copyPropertyList(class, &propertyCount);

    

    for (unsigned int i = 0; i < propertyCount; ++i) {

        objc_property_t property = properties[i];

        const char * name = property_getName(property);

        [propertyNames addObject:[NSString stringWithUTF8String:name]];

    }


    return [propertyNames copy];

}



Trackback 0 : Comment 0

서버개발자 그리고 아이폰 개발자

Project 2011.12.05 23:50
서버사이드 개발자에서 전문적인 아이폰 개발자로서 약 7개월정도가 지난것같다.
물론 이전에도 주말에 취미로 또는 회사에서 프로토타입정도로 아이폰 및 OSX에서 개발을 한적은 있지만
이렇게 풀타임으로 개발한적은 이번이 처음이기 때문에 기점을 올해로 잡는다.

 그동안 아이폰 개발을 하면서 느낀것을 몇개 정리하면


1. 쉽지 않은 Objective-C개발
자바로 웹페이지를 개발하는데 있어서 소스 코드의 완성도는 뒤로 두고서라도
화면에 원하는 데이터를 표시하는데까지는 그다지 시간이 걸리지 않지만,
아이폰에서 원하는 화면을 만들기 위해서 선택할수 있는 방법은 많지가 않다.
뷰를 구성하는 컴포넌트들의 특성과 구조를 이해한다음에야 각각의 뷰를 화면에 붙일수가 있는데
애플이 제공하지 않는 뷰의 디자인을 수정하기 위해서는 더욱더 굉장히 많은 학습시간이 필요하다.
(물론 전부 이해한뒤에는 쉽게 수정이 가능할정도로 뷰의 프레임워크는 정말 정말 잘 짜여저 있다.)

개인적으로는 자바보다 3배는 시간을 들여야 비슷한 퍼포먼스를 낼수 있을거라 생각한다.
물론 그뒤에는 자바보다 3배이상 빠르게 개발이 가능할듯하다.


2. 디자인이 90%이다.
어느정도의 불폄함은 감수해가며 사용하는 웹사이트와는 달리
항상 손에 들고 다니며 사용하는 앱의 특성상 아름다운 디자인은 유저의 손을 붙들어 놓는데 가장 큰
요인이라고 말할수 있다. 또 앱의 전환이 홈버튼과 클릭 길어야 2초밖에 걸리지 않기 때문에,
다른 앱과의 경쟁에서 이기려면 기능도 중요하지만 사용자 UI 및 UX가 더욱더 중요한 부분을 차지하게 된다.


3. 테스트 그리고 테스트
아이폰의 앱은 뷰와 데이터와 콘트롤러를 가진 내부적으로 하나의 완결된 어플리케이션으로서 존재하기 때문에
그만큼 많은 테스트를 필요로 하게 된다.
서버 개발 할때는 기능 및 시나리오 테스트정도로 상대적으로 뷰의 테스트가 간단했다면
아이폰의 테스트는 대부분이 뷰와 관련된 테스트라고 할정도로 뷰관련 테스트가 많다.
디자인이 그만큼 중요하기 때문에 1PX 하나하나 체크하고 수정해야하는 부분이 생각보다 시간이 많이 걸렸다.


4. 많은 사용자의 피드백
쉽게 다운로드 받아 매일 사용하는 만큼 유저로부터의 피드백은 상상을 초월할정도로 많이 온다.
한번 개발한 서버쪽 프로젝트의 피드백은 거의 관계자에게서 받아 그렇게 양이 많지 않지만(볼륨이 큰만큼)
앱에서는 엔드유저의 폭발적인 피드백을 볼수 있다는 점에서 보람과 부담을 동시에 느끼게된다.
하루 twitter로 RT되는 양이 상상 초월하기 때문에 앱을 버젼업 할때마다 버그가 없는 제품을 내기위해 엄청난
압박을 받기도한다. 
한번은 유저의 클레임으로 앱스토어에서 삭제된 적이 있는데, 복구하는데 약 2주정도 걸렸던 기억이 있다.
그 이후로는 잘못된 정보가 퍼지지 않도록 회사 CS(customer service)를 강화하고 앱내에도 문의페이지를 넣는등 많은 신경을 썼었다.


5. 애플의 심사
앱의 심사는 보통 일주일 정도 걸린다. 긴급심사의 경우 하루나 이틀정도로 통과시켜주기도 급한 경우가 아니면 자주 이용하지 않는 편이 좋다.
이번 앱의 경우 리젝트도 여러번 당했었다. 한번은 private api를 이용했다는 이유로 리젝트 당하기도 했었고
앱의 기능에 대해 오해해서 리젝트 당하기도 했었다.
때문에 예상대로 심사가 통과하지 않았을경우의 스케쥴링 , 충분한 여유를 두고 심사를 넣는것이 좋다.


 결론을 이야기하자면 아이폰앱의 개발은 전혀 다른 도메인에 집중해야할 부분이 틀리기 때문에
서버개발과는 전혀 틀린 개발 프로세서와 지식이 필요하다. 하지만 한번 공부해서 개발해볼 가치가 있을정도로
개발이 즐겁다. XCODE도 쓰다보면 상당히 편리하고, Cocoa Framework 또한 아름답게 짜여진 프레임워크라
많은 공부가 된다.

 현재 만들고 있는 앱의 유저는 약 700만명으로 올해 목표를 이미 7배나 지나 초고속으로 성장중이다.
열심히 만든 보람도 있지만 릴리즈 때마다 그만큼의 신중함이 요구되는 유저수이기도하다.
 하지만 아직 구현해야할 기능들이 많이 있는데다 이 많은 유저들과 앱을 발전시킬 생각을 하면 
내년 또한 상당히 기대가 된다.
 

 
Trackback 0 : Comment 0

소프트웨어에서의 추상화 그리고 상속,다형성,캡슐화

Project 2009.07.01 23:22
 써니님의 추상화에 대한 글에 제글이 인용되어 있기에 다시한번 제 생각을 정리해야할듯 해서
글을 씁니다.   

 1. 추상화는 무엇?

 이전의 글(추상화와 실용주의)에서 언급했듯 추상화란 인간의 본능이자 특성입니다.
우리를 둘러싼 복잡한 환경에서 좀더 현명한 판단을 위해 사물을 단순화 시키는 것을 말합니다.
우리는 추상화를 통해 사물의 특성을 뽑아내고 불필요한 부분을 제거합니다.
하지만 이런 추상화를 하는데 있어 중요한것은 하위 개념을 포함하는 개념을 추출하는데 있습니다.

 2. 객체 지향이란?

 객체지향이란 아래의 두가지 측면으로 생각해볼수 있습니다. 
 
 a. 철학적인 측면
  플라톤의 이데아론에서 말하듯 우리를 둘러싼 모든 것들은 이상의 것(이데아)에서 파생한것(객체)이라
보는데서 클래스와 인스턴스의 관계를 나타낼수가 있고, 또는 모든 사물을 객체로 보고 객체간의 메세지를 
주고받는 개념(세포)으로 보는 관점등이 있습니다.
   
b. 설계와 구현의 측면
-객체지향 분석 및 설계(OOAD (Object-oriented analysis and design))
 실세계를 정의하기위한 기술로서의 객체지향을 말할수 있습니다.
해결하려는 실세계의 문제를 분석, 정의, 분류를 한뒤 구현을 위한 설계까지의 단계를 말합니다.

-객체지향 구현기술
 객체지향적 개념을 구현하는데 있어 도움주는 언어적 지원 , 기술등을 이야기합니다.
객체지향 언어, 디자인패턴등 구현에 관련된 모든 기술을 말합니다. 

 3. 상속 , 다형성 , 캡슐화?

 일반적으로 객체지향적을 이야기하며 말하는 세가지 개념이지만 얼마전 강규영님이 언급했듯 
객체지향이라는 패러다임에서 갑자기 나온 새로운 개념들은 아니라고 생각됩니다.
제가 보는 측면은 실용주의 입니다. 즉 위의 모든것은 개념은 실용적인 측면에서 나왔다고 보는 입장입니다.

 a. 상속은 재사용성?
 상속은 재사용의 측면에서 이해할수 있습니다.
상속은 같은 동작을 하는 코드를 쉽게 재사용하여 수정할수 있도록 도와줍니다.
하지만 일반적으로 재사용은 상속을 이용하지 않아도 가능하며 여러 문제점을 불러 일으키기에
최근에는 구성을 활용하는 것을 추천하지만 상속도 적절히 사용하면 쉽게 문제를 해결하는 
방법이 될수가 있습니다.

b. 다형성은 결합도?
 복잡하게 얽혀있는 소스코드들 사이에 존재하는 결합도를 줄이기 위해서 도입된 개념입니다.
한가지 통로를 통해 같은 행동을 하는 객체들을 제어할수가 있습니다.  


c. 캡슐화는 복잡도
 캡슐화에 대해서는 이전 접근제한자에 대해 쓴 글에서 언급했듯, 다른 소스코드를 이용함에 있어서
알 필요가 없는 정보를 숨기며 필요한 인터페이스만을 제공해 복잡도를 제어하는 기술입니다.
 우리가 다른사람의 소스 코드 및 라이브러리를 사용함에 있어서 인터페이스 정보만 알고도 이용할수
있는 것은 이 개념에 의해서 입니다.


d. 그밖에.. interface , abstract 
 Interface 및 Abstract에 대해서는 예전에 쓴 글에서 언급했듯, 
순전히 다형성과 상속을 구현하기 위해서 도입된 개념입니다.(없어도 객체지향을 구현하는데는 문제없습니다.)
 하지만 앞서언급한 글에 나타나있지않은 다른 측면은 강제구현에 있습니다.
즉 많은 사람들이 함께 개발함에 있어서 구현에 제약을 강하거나 , 강제함으로서
개발 생산성과 질을 높일수 있습니다.




 위의 abcd에서 말한 개념들은 객체지향 언어마다 다른 방식으로 구현되어 있습니다.
 또 위의 글은 어디까지나 제가 보는 관점의 이야기입니다. 
사물을 보는 방법은 여러가지가 있을수 있다고 생각합니다.
 객체지향을 IF문의 제거로 볼수도 있고, 단일지점제어의 관점으로 볼수도 있듯 정답은 없다고 생각하네요.


Trackbacks 2 : Comment 1

정말 다형성(서브타입)이 IF를 줄일수 있을까?

Project 2009.06.25 01:56

 얼마전 강규영님의 글 "OOP란 조건문(if)을 줄이는 것"을 보고
정말 서브타입 다형성(subtype polymorphism) 이 if,else를 줄일수 있는가 생각해보았다.


예를들면 아래와 같은 클래스가 있다고 생각을 해보자.
식사 {
        밥() {
                if (아침) {
                   return 빵과우유;
                } else if (점심) {
                   return 짜장면;
                } else if (저녁) {
                   return 삼겹살;
                }
        }
}
아침 점심 저녁을 비교하는 세개의 IF문이 존재한다.
이 클래스를 아래와 같이 Interface를 이용해 분리를 해보겠다.

// 인터페이스
interface Food {
        eat();
}


// 오전을 나타내는 클래스
class Morning implements Food {
        eat() {
           return 빵과우유;
        }
}

// 오후을 나타내는 클래스
class Afternoon implements Food {
        eat() {
          return 짜장면;
        }
}

// 저녁을 나타내는 클래스
class Evening implements Food {
        eat() {
          return 삼겹살;
        }
}

class Meal {

        Food s;.

        // 식사지정 메소드
        setFood(Food s) {
           this.s = s ;
        }

        // 밥먹기
        eat() {
           return s.eat();
        }
}



public MealMain {
        public static void main(String[] args) {

                Food morning = new Morning();
                Food afternoon = new Afternoon();
                Food evening = new Evening();
                        

                Meal ml = new Meal();

                // 아침                
                ml.setFood(morning);
                print(ml.eat());

                // 점심                
                ml.setFood(afternoon);
                print(ml.eat());

                // 저녁                
                ml.setFood(evening);
                print(ml.eat());


        }
}

간단한 소스코드라서 별로 어렵지 않을것이다 (내가 복잡한걸 못 짠다.-_-)
결과적으로 IF문이 없어져 버렸다.

그런데 정말 다형성으로인해 IF문이 줄었던것일까?

public MealMain {
        public static void main(String[] args) {

                Morning morning = new Morning();
                Afternoon afternoon = new Afternoon();
                Evening evening = new Evening();
                       
                // 아침               
                print(morning.eat());

                // 점심               
                print(afternoon.eat());

                // 저녁               
                print(evening.eat());


        }
}
이 코드또한 다형성을 이용하지 않고도 방금전 코드와 같은 동작을 한다.

다시한번 반문해보자. 정말 다형성이 IF문을 줄였는가?
소스코드의 의도적인 리팩토링으로 인해 나타난 결과는 아닐까?

다형성은 객체간의 결합도 및 의존성을 줄이고
의존성 역전은 그 결과 부수적으로
가능하게된것은 아닐까?


OOP는 IF문을 줄일수가 있다.
(사실 이건 언어적 관점에서 IF문을 줄일수 있는것이다. 결과적으로 비교하는 로직은 없앨 수가 없다.)
하지만 다형성으로 IF문을 줄일수 있다는것은 주객이 전도된 이야기가 아닐까생각한다.
즉 IF문을 줄이기위해(결합도를 낮추기위해) 생겨난 , 필요한 특성이 아닐까?

p.s 강규영님의 의존성역전과 순환참조는 재미있게 읽었습니다.
Trackback 1 : Comments 8

객체 지향과 절차지향 단상.

Project 2009.04.25 02:01
 오늘 갑자기 떠오른 객체지향에 대한 단상을 그림으로 옮겨보았다.
(허접한 영어는 이해를..-_-)


 쉽게 설명을 하자면,

현실세계를 컴퓨터로 구현하는데 있어서 먼저 현실세계의 요구사항 및 제약사항을 파악하여
정리하는 일 즉 모델링 이란 작업이 필요하다.
그런 뒤에야 정의된 사양에 맞추어 구현하는 작업 즉 구현작업에 들어갈수가 있다.

여기서 프로그래밍에 두가지 틈이 생기게 되는데
1. 실세계를 모델링하는데 있어서 누락되는부분.
2. 모델링을 구현함에 있어서 부족한 부분.

객체지향이 인기를 끄는 이유는 1과 2번의 효과적인 보완에 있다.
이전의 모델링에 비하여 현실세계를 좀더 가깝게 모델링할수가 있고,
(OOAD로 통하는 UML , 객체지향 분석,설계 모델)
이전의 구현방법에 비하여 보다 충실하게 구현할수가 있다.
(OOP 및 디자인패턴)


p.s 미리 언급하는 그림의 오류
1. 문제정의 공간(problem definition space)에 있는 객체지향 , 절차지향이란 단어는 그 두가지로
모델링을 나눌수 있다라고 하기보다는 객체지향 모델링과 그 이외의 모델링을 효과적으로 대조시키기 위하여
일부러 절차지향은 언급함.

2. 문제 해결공간(problem solution space)에서 언급한 절차지향 방법또한 위의 맥락.


Trackback 0 : Comments 2

프로그래밍을 하면서 수학과 포인터가 필수인가요?

Project 2009.04.22 22:42
최근 아는 블로거들 사이에서 이슈가 되고 있는 수학공식과 포인터에 관한 내 의견을 이야기하자면
참 쓸대없는 소모적인 논쟁인것같다.

먼저 프로그래밍을 할때 수학이 필요할까?
이 질문에 대한 답은 예전에 쓴 글(수학과 컴퓨터) 에서 이미 언급한적이 있다.
당신이 수식에 관련된 대상에 대해 프로그래밍을 한다면 필요하겠지만 그렇지 않다면
그다지 필요성은 못느낄것이다. 내가 지금까지 프로그래밍을 하면서 사칙연산 이상의
수학실력이 필요하다고 느낀적은 없다.

그럼 수학과 논리력과의 관계는 어떨까?
많은 사람들이 착각하고 있는 것이 있는데,
논리력과 수학의 관계는 인과관계 즉 필요조건이지 충분조건이 아니다.

말하자면 수학을 잘하는 사람은 논리력을 가지고 있지만 수학을 못한다고해서 논리력이
없다고 판단하는것은 잘못된 것이다.

나 또한 프로그래밍을 하는데 논리력이 필요하다는것은 동의하는 바이다.
하지만 그 논리력이 수학이 전제되어야만 나온다고 생각하지 않는다.
기본적으로 논리력은 수학이 전제되지 않은 다른 많은 직업에서도 필수적인 항목이다.
예를들면 변호사,의사,작가,신문기자,편집자 등등 심지어는 디자이너까지 논리력은 중요한 능력이다.
이러한 직업을 가진 사람들이 모두 수학을 잘했을까?
수학은 수를 다루는 기술의 일종이다. 이 기술에 대해 쉽게 적응하여 능숙한 사람이 있고 그렇지 않는
사람도있다. 이 기술을 가지고 그사람이 논리력이 있다고 판단하는것은 섣부른 결정이다.

길다고 말할수 없지만 지금까지 내가 경험한 프로그래밍은
1. 고객이 원하는 프로그램의 요건을 정의
2. 정의된 요건에서 구현하려는 사양을 추출
3. 추출된 사양을 구현
이라고 라고 말할수 있는데
이중 1,2번이 프로그래밍에서 가장 큰 비중을 차지하고 있고 3번에 해당하는 구현은
프로그래밍의 일부분에 지나지 않는다.
또한 1과 2에서 필요한것은 논리력이지 수학공식이아니다.

그럼 이제 포인터로 넘어가자.
포인터를 모르면 프로그래밍을 포기해야하나요?

난 지금까지 포인터를 언급하지 않고도 자바를 이해하는데 전혀 문제가 없었다.
(이쯤에서 미리 방금언급한 포인터에 대해 정의를 한다. 여기서의 포인터는 C언어 및 C++의
포인터를 말한다.)
 나 말고도 수많은 사람들이  C언어의 포인터를 모르고도 PHP,JAVA등의 언어를 이해하고 이용하며
구현하는데 있어서 큰 문제를 못느껴왔다. 그러면 사람들은 이런 질문을 할것이다.

"그럼 추상화의 구멍은요?"


많은 사람들이 포인터를 모르면 알수없는 에러와 버그에 고생을 할것이다라고 말한다.
그게 사실일까? 위의 설명은 일부분만의 사실을 이야기하고 있다.
당신이 포인터를 가지고 얼마나 많은 버그들을 고치고 에러의 원인을 발견했는가?

대부분 언어의 사양수준에서 해결되지 않는가? 단지 일부분의 발견하기도 힘든 버그를 위하여
로우 레벨의 언어까지 익혀야한다고 말하는것인가?
모든사람이 하나의 버그를 해결하기위해 내부구조까지 알아야한다는이야기인가?

난 오히려 그런사람들에게 이렇게 묻고싶다.

"당신이 커버할수 있는 추상화의 범위는?"

얼마나 낮은 레벨의 구현까지 이해하지않으면 안되는 것인가? 한사람이 감당할수 있는
범위는 분명 존재한다. 누구나 그 범위를 만족해야한다고 생각한다면 그것은 잘못된것이다.
IT 비지니스 전문가가 낮은 레벨의 상세한 구현까지 알아야한다고 말할것인가?
그런일들은 그쪽 도메인에 전문가에게 맡기는것이 빠른일이 아닌가?

보통 성숙된 공학의 다른 분야들은 각각 추상화의 레이어에 해당하는 전문가들이 존재한다.
만약 프로그래밍의 에러의 원인이 정말 낮은 수준에서 일어난다면 우리는 그쪽 분야에 해당하는
전문가에게 맡기면 되는것이다.

내가 하고싶은말은 한가지이다.

"현재 당신의 포지션을 보고 또는 미래의 포지션을 생각해 당신이 쌓아야할 지식을 공부하세요."

또한 이것은 당신이 담당하고 있는 도메인에 관한 이야기이다.

Trackback 0 : Comments 4