'전체'에 해당되는 글 289건

  1. 2015.04.04 블로그 이전
  2. 2013.05.26 합격하는 이력서의 공통점?
  3. 2013.05.17 DeNA 개발자 주최 아이폰 개발자 스터디?
  4. 2012.11.16 이 블로그를 종료합니다.
  5. 2012.10.17 Coredata Background 처리에 관하여
  6. 2012.04.15 PHP 단상
  7. 2012.04.13 JSON data로부터 간단히 모델 클래스를 구현하기
  8. 2012.03.04 블로그의 정체성
  9. 2012.03.04 아직도..
  10. 2011.12.05 서버개발자 그리고 아이폰 개발자

블로그 이전

분류없음 2015.04.04 19:09

가뜩이나 관리하지 못하는 블로그이지만

일본ip가 자주막혀서 더 관리하기가 힘들어졌기 때문에 wordpress로 이전합니다.


https://kvomisa.wordpress.com/


p.s 텀블러도 고려해봤지만 글쓰기보단 사진 보기에 최적화된 사이트라 포기

Trackback 1 : Comment 0

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

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

이 블로그를 종료합니다.

분류없음 2012.11.16 00:03
개인적으로 인터넷의 무효한 링크를 굉장히 싫어하기때문에
거의 사용하지 않는 블로그였지만, 내 블로그를 통해 조금이라도 도움이 될사람이 있다면
기꺼히 그리고 서비스가 죽지않은한 영원히 남겨둘 생각이었다.

하지만 최근에 비공개된 글이 타 검색사이트에 공개가 되어있다는 것을 알고는
다음에 항의했지만, 지금까지 2주째 답장이 없기때문에 , 나로서는 더이상 이 블로그를
유지하는것은 무의하다고 판단하게 되었다.

내 블로그를 보는 몇명 안되는 유저들을 위해 마지막 인사를 남긴다.
 
さようなら


p.s 새로운 대안 블로그가 생기면 이 블로그의 모든 글은 삭제될 예정입니다. 
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

블로그의 정체성

Diary 2012.03.04 23:13
 이 블로그의 시작은  내가 알고 알고 있는 지식 및 생각의 공유, 그리고 다른사람의 의견을 묻기위한 블로그로서 시작해서 기술블로그로 잠깐(!) 방향을 선회했다가 다시 공상블로그로 돌아갔다가 이젠 초심으로 돌아가 지식의 공유 및 다른사람들의 의견공유(지금 페이지 뷰를 보건데 아마 거의 없을듯하지만)를 목적으로 글을 써야겠다.
 뭐 잡담도 가끔(아니 대부분)..



 
Trackback 0 : Comment 0

아직도..

Diary 2012.03.04 22:50
정말 오랜만에 블로그에 글을 쓴다.

글을 쓰려고 블로그를 둘러보니 먼저 놀란것은 아직도 이명박의 시계는 356일이나 남았다는 것이다.
이 블로그 한창 쓸때 이명박이 대통령이었는데, 그 오랜 시간이 지나도 아직도 이명박이 대통령이구나.
5년이란 시간은 정말 긴시간인것같다.

5년내동안 내게 생긴일을 정리해보자면 (개인적인 일은 빼고)

1. 전직

 아마 지금 회사보다 큰회사는 그다지 많지 않을정도로 큰회사로 전직을 했다.
이전 회사생활보다 모든면에서 만족스러운 근무형태를 제공해주고 있다.
사내 카페라든지, 플렉서블 타임이라든지(장단점이있지만,늦잠이 많은 나에겐 장점이 많은듯),
뛰어난 동료라든지 , 자동화된 환경이라든지, 휴가 쓰는데 눈치안보이는점등등등.
아마 한동안은 전직생각은 안해도 될것같다. (글쎄?)

1-1. 프로젝트의 성공

 지금 하고 있는 프로젝트의 성공으로 나름 회사에서 위치를 인정받기 시작했다.
곧 월급도 오를것같고 인센티브 또한 최고평가점수에 맞게 받았고, 내 경력에도 많은 도움이 될것같다.
하지만 그에 따라 일도 점점 늘어나고 있는데다 유저도 점점 늘어나고 스펙도 점점 다양해져서
아마 올해동안에는 이 프로젝트만으로도 충분히 보낼수 있을것같다
아마 내년쯤엔 좀더 높은 자리에서 다른 프로젝트를 진행할수 있는 사람이 될수 있을지도 모르겠다.


2. 투잡

 몇년전부터 아는 사람들과 해오던 투잡일이 제작년 릴리즈를 해서 유료 카테고리 랭킹1위, 전체순위 3위에
올라간적이 있을정도로 잘 풀리는듯 했지만 현재는 다들 이런저런 개인적인 이유로 인해 근 1년이상 멈춘상태로 있다.
올해안에 이쪽일에도 집중을해서 좋은 결과를 낼생각이다. (돈은 별로 못벌었음. 서버비용정도는 벌은듯...)


이것이외에도 그동안 일어난일은 많이 있지만 지금 생각나는것은 이정도뿐인듯.


 
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