Memory allocation without using sizeof https://developer.apple.com/library/ios/documentation/General/Conceptual/CocoaTouch64BitGuide/ConvertingYourAppto64-Bit/ConvertingYourAppto64-Bit.html#//apple_ref/doc/uid/TP40013501-CH3-SW21 +[NSObject load] method without an @autoreleasepool http://www.mikeash.com/pyblog/friday-qa-2009-05-22-objective-c-class-loading-and-initialization.html Macro-based include guard http://en.wikipedia.org/wiki/Pragma_once Retaining or copying delegate https://developer.apple.com/library/ios/documentation/general/conceptual/CocoaEncyclopedia/DelegatesandDataSources/DelegatesandDataSources.html Constructor return type http://stackoverflow.com/questions/8972221/would-it-be-beneficial-to-begin-using-instancetype-instead-of-id Setter invocation in init or dealloc method https://developer.apple.com/library/ios/documentation/cocoa/conceptual/ProgrammingWithObjectiveC/EncapsulatingData/EncapsulatingData.html#//apple_ref/doc/uid/TP40011210-CH5-SW11 http://stackoverflow.com/questions/5094615/calling-a-method-on-self-while-in-dealloc https://developer.apple.com/videos/wwdc/2012/ : WWDC 2012 Session video “Migrating to Modern Objective-C” (around 23min) http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml?showone=Avoid_Accessors_During_init_and_dealloc#Avoid_Accessors_During_init_and_dealloc Terminating the app in a release build https://developer.apple.com/library/ios/qa/qa1561/_index.html Category used for “private” declarations https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/CustomizingExistingClasses/CustomizingExistingClasses.html IBOutlets in public interface https://developer.apple.com/videos/wwdc/2012/ : WWDC 2012 Session video “Migrating to Modern Objective-C” Method swizzling http://stackoverflow.com/questions/5339276 Unprefixed category method https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/CustomizingExistingClasses/CustomizingExistingClasses.html Missing device type resource https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/LoadingResources/Introduction/Introduction.html#//apple_ref/doc/uid/10000051i-CH1-SW2 Weak reference to top-level XIB object https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html#//apple_ref/doc/uid/10000051i-CH4-SW6 Unknown resource file name modifier https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/LoadingResources/Introduction/Introduction.html#//apple_ref/doc/uid/10000051i-CH1-SW2 https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/LoadingResources/ImageSoundResources/ImageSoundResources.html#//apple_ref/doc/uid/10000051i-CH7-SW17 Recommended compiler warning options http://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-command-line-flags https://developer.apple.com/library/ios/documentation/DeveloperTools/Reference/XcodeBuildSettingRef/1-Build_Setting_Reference/build_setting_ref.html#//apple_ref/doc/uid/TP40003931-CH3-SW105 http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html Missing API usage description https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW1 Class implements -isEqual: but not -hash Cocoa Core Competencies: Object comparison Throwing an Objective-C exception http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml?showone=Avoid_Throwing_Exceptions#Avoid_Throwing_Exceptions https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Exceptions/Exceptions.html Shortcut initializer http://stackoverflow.com/questions/719877/use-of-alloc-init-instead-of-new-objective-c Casting the return value of malloc() http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc/605858#605858 https://www.securecoding.cert.org/confluence/display/seccode/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type Globally caching a thread-unsafe class instance https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html Fixed-format NSDateFormatter not using invariant (POSIX) locale https://developer.apple.com/library/ios/qa/qa1480/_index.html Conflicting category methods https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/CustomizingExistingClasses/CustomizingExistingClasses.html
CocoaPods podfile configuration or setup for scheme or build configuration
CocoaPods를 이용하는 프로젝트에서 스키마나 빌드설정에 따라 의존 라이브러리를 지정하고 싶은 경우가 발생한다.
3단계로 설정할 수 있다.
podfile 설정
project build setting 변경
edit scheme
차례차례 설정해보자.
podfile 에서는 기본 target에 맞춰서 라이브러리를 설정하는 것이 아니라 Test Target 에 해당 pod spec을 설정하면 된다.
target :test , :exclusive => true do
pod 'FLEX', '~> 1.0.0'
end
project 설정 -> 기본 target -> build setting -> Other Linker Flags 에서 원하는 configuration에 -force_load 항목을 추가한다.
-force_load $(CONFIGURATION_BUILD_DIR)/libPodsTests-FLEX.a
Build할 때 원하는 라이브러리에 대한 archive 파일이 없을 수도 있기 때문에 build target dependency를 지정하기 위해
Edit Scheme -> Build -> Targets 에서 +버튼을 눌러 원하는 항목을 추가한다. (위에서는 libPodsTests-FLEX 에 해당) 적절한 phase에 따라 포함 여부를 설정한다.
위와 같은 설정에 대한 방법이 딱히 구글 검색을 해봐도 나오지 않는데 xcode의 빌드 과정에 대한 이해가 있으면 손쉽게 구성할 수 있기 때문이 아닐까? 생각한다.
header 파일은 include 되기 때문에 force_load 하지 않는 configuration에서는 컴파일 시 Symbol을 찾지 못한다는 오류가 나온다. NSClassFromString 이나 perform selector를 적절하게 이용하고 wrapper를 사용해서 다른 코드와 분리 시키면 된다. macro로는 if문을 명확하게 검출할 방법을 찾지 못해서 사용하지 못했다.
1. 문제 파악 능력(Problem Decomposition) 프로그래밍은 문제 해결 작업입니다. 코드를 작성하기 전에 문제 해결 방법을 명확하게 알아야 하고 그러려면 문제를 해결하기 쉬운 작은 단위로 분해나는 능력이 필요합니다. 2. 시나리오 분석(Scenario Analysis) 프로그램이 처한 다양한 환경을 고려해서 다양한 예외 상황을 가정하고 그에 맞게 대응합니다. 3. 작명(Naming) 프로그램을 작성하다 보면 끝없이 이름을 짓게 됩니다. 클래스, 메서드, 변수 등의 이름을 잘 지은 프로그램은 코드 자체가 문서의 효과를 냅니다. 의미 있는 이름을 붙이다 보면 코드의 구조도 좋아집니다. 작명은 쉬운 일도 아니고 여러번 번복해야 하기도 합니다. 작명을 하다 보면 사용하는 개념에 호칭이 생기고, 호칭을 사용하다보면 그 개념을 일관되게 적용해 프로그램을 작성하기 쉬워집니다. 4. 일관성(Consistency) 프로그래밍에서 복잡도를 다루는 과제가 가장 극복하기 어렵지 않을까 합니다. 복잡도와 싸우는 한 방법이 일관성입니다. 일관성으로 인해 복잡한 가운데에서 패턴을 발견해서 처리 방법을 구분하고 우발적인 복잡성이 아닌 본질적인 복잡성에 집중하도록 합니다. 일관성은 작명, 모듈 구성, 디렉터리 구조 등 다양한 곳에서 중요하게 적용되어야 합니다. 프로그램을 수정하다 보면 일관성이 깨질 수 있는데, 부주의한 프로그래머는 추가하는 부분이 기존의 일관성을 해치는지 따지지 않지만 좋은 프로그래머는 사소해 보이는 것에도 철저합니다. 일관성이 북잡도와 싸우는데 얼마나 중요한지 알기 때문이지요. 5. 학습(Learning) 소프트웨어 개발자로서, 우리는 끈임 없이 배웁니다. 새로운 요구 사항을 처리하기 전에 그 요구사항을 이해해야 합니다. 기존 프로그램에 코드를 추가하기 전엔 기존 코드를 학습해야 합니다. 새로운 기능이 올바르게 동작하려면, 연관된 시스템도 배워야 합니다. 빨리 학습하는 능력은 훨씬 유능한 개발자가 되게 해줍니다. 게다가, 소프트웨어 공학 영역이 발전하는 속도는 매우 빠르기 때문에 배워야 할 새로운 언어, 도구, 기술, 프레임워크가 계속해서 소개됩니다. 배운다는 건 그 자체로 즐거움이고, 개발자의 삶은 지겨울 틈이 없다는 뜻이기도 합니다. - 너무 좋아서 페이스북의 성철님 포스팅을 무단 복제함...
If you want to make a good (Internet) service in Korea, Become the manager as fast as.
신규 서비스를 런칭하고 1년이 다가온다. 프로토타입을 진행했던 3인 중 한명으로 수평적 문화가 수직적 문화로 변화되면서 느낀 점 중 가장 나를 힘들게 했던 상황에 대해 남기고 싶었다.
혹자는 어떻게 평가할지 모르겠지만, 새롭게 서비스를 구성하면서 여러가지 시도들을 하는데 있어서 새로운 아이디어를 내는 입장이라기 보다. 그 아이디어의 검증과 보완책들을 여러가지 냈었는데 시간이 많이 부족했음에도 불구하고 그런 검증들이 결국 서비스가 성장할 때 발생할 수 있었던 문제들을 줄일 수 있었고 확대 해석하면 서비스 성장에 도움을 주었다고 평가하는데 예를 들면 전화번호 복구 로직에서의 보장해주는 부분과 보장하지 못할 부분들을 나눈다던지, OS에서 제약을 한 기능을 서버 연동을 통해 우회 한다던지 하는 기능들이 있었다.
이런 것들이 가능했던 이유 중 하나는 누군가 의견을 내면 우리 모두가 한번씩은 생각해보고 추가 의견들이 논의되고 반영되는 문화가 가능했던 것 같다. 심지어 타당하다고 생각되면 대표 이사님의 생각을 그대로 반영할 수 없으니 수정안으로 하자고 반발(?)하고 그 결과가 반영된 적도 있었다. 그에 따른 flow가 OS 기조에 맞춰졌었다.
여기까지가 수평적 문화가 강했었던 시절이다.
막상 서비스가 오픈되고 성장이 잘되어 인력들이 투입되기 시작하자. 문화에 변화가 발생했다. 일년 전 오픈 직후에는 파트에 혼자 남게 되었는데 다른 파트들도 사정은 비슷한 상태였기 때문에 이전의 문화를 유지할 방법이 없었다. 그 이후 신규 인력들이 들이닥치고 할일들이 급속도로 늘어나게 되자. 세심하게 서비스를 보담는 것보다 요구사항들을 처리에 급급하게 되는 전형적인 일에 치어 사는 상황에 놓이게 되고 일의 진행 여부와 협업에 삐그덕 거리게 되었다. 이제 실무 개발자들은 효율성 강화의 명목으로 슬슬 논의에서 빠지게 되고 각 파트의 리더들 모임에서만 서비스를 고민하게 되며 할 일들은 이미 결정되어 내려오는 형국이 되었다.
이제 제일 힘든 일들이 등장하게 되었는데, 모든 것들이 결정되어 내려오는 상황에서 실제 적용 시 예상과 다르게 발생하는 일들이 생기게(생길 수 밖에 없지 않은가?) 되었는데 상위로 의견을 올리고 싶어도 너무 오래 걸리고 너무 많은 사람들이 각자 이야기하고 채널은 여전히 팀장 한명에 국한된 상황에 놓이게 되었다. 플랫폼에 따른 구현 방식이 변경되어야 할 점들이 의사 결정 기구에 참가하지 못한 사람들에게서 제기되고 이것들이 의사 결정권자들에게 전달이 되지 않고 그대로 (일정 때문에) 강행하게 되는 현상이 지속적으로 나타나며 품질은 떨어지고 기술 부채들은 쌓이게 되었다.
더 큰 문제는 모든 사람의 의견을 들을 수도 없고 너무 많은 이슈들이 제기되기 때문에 개개인의 의견의 무게는 이전보다 가벼워지고 의사 결정권자들의 의견들은 이전부타 더 무거워지면서 보완을 할 방법이 사라져가고 있다는 것이다. 이제 문제가 예상이 되어도 이이를 제기하지 않는 문화가 자리잡아가고 있었다.
회사에서 내놓은 해법은 중간 관리자를 더 투입하는 것이었다. 그것으로 수직적 조직 문화는 완성이 되었으며, 협업하는 업무가 아닌 것에 대한 의견은 상위 조직장에게 올리고 다시 실무자에게 단계적으로 내려오게 되었다. 이 상태에서 어떻게 스타트업의 기민함을 유지할 수 있을까?
여기까지가 서비스를 만드는 사람으로 이해되던 시절에서 코드를 만드는 사람으로 취급 받는 시절까지 변화에 대한 간단한 소감이다.
이 이야기를 꺼내게 된 단초는 이번주 초 지표에 이상 징후가 나타나고 이를 추적하는 과정에서 모두들 당연시 하는 부분이 있어 그 부분이 문제가 될 수 있다는 의견을 제시해 보았지만 묵살되고 접근 권한이 없기 때문에 데이터로 검증할 수도 없어 무기력에 빠진 적이 있었는데 오늘 데이터를 들여다 보고 실제 그런 일이 발생할 수도 있다고 결론이 나와서 관리자 대비 내 의견의 얼마나 가볍게 취급되고 있는지 느낄 수 있었기 때문이다. 물론 내 의견들이 여러차례 검증되고 인정받게 되면 신뢰도가 높아져서 더 무겁게 취급 받을 수 있겠지만, 너무 오래 걸리고 동료들은 수시로 교체되니 매번 신뢰를 쌓는 것도 고된 일이다. 마치 수학 정석책의 첫 단락인 집합만 보는 느낌이라고 할지...
최근 보고 있는 태평양 전쟁 역사를 보면 일본에 비해 미국에서 더 잘했던 점들 중 하나는 전투의 성공이나 실패를 면밀히 분석하고 (이는 양측 다 했었지만) (좋은) 그 교훈을 다음 전투에 반영 시킬 수 있는 시스템을 만들기 위해 많은 노력을 해왔다는 것이다. 과연 우리나라 IT 회사들은 매일 매일 발생하는 전투들의 교훈들을 조직에 녹여낼 역량이 되는 것일까? 그렇지 않다면 나는 최대한 빨리 관리직으로 승진하는 것을 최대 목표로 삼아야 한다고 나름의 교훈으로 삼아야 한다. 그러고 보니 가장 빨리 관리직으로 가는 방법을 스타트업을 만들거나 스타트업에 합류 하는 것이구나.
작성은 Aug 2nd, 2013 11:04am
근 일년만에 글을 올려둔다.
작년에 많은 일들이 있었고 상처 받은 일들이 있었기 때문에 너무 흥분한 것은 아닌지 걱정하면서 묻어둔 글이다. 차라리 못난글이었으면 좋겠다.
Apple Swift ( https://developer.apple.com/swift/ ) 가 WWDC에서 발표했을때 느꼈던 부분이 Javascript가 Node.js ( http://nodejs.org )를 발판으로 새로운모습을 보였던 것처럼 Swift도 Server Side 에서 이용하면 좋을 것 같다라는 느낌이 들었다. WebObjects ( http://en.wikipedia.org/wiki/WebObjects )에서는 어떻게 해석을 했던 것인가? 의문이 들어서 osxdev에 질문 글( https://www.facebook.com/groups/osxdevorg/permalink/810973695582552/ )을 올려본 적도 있고 주변 사람들에게 어떻게 생각하는지 물어보고 했는데 역시 Hacker News! Server 에서 Swift를 사용하는 방법에 대한 글( https://news.ycombinator.com/item?id=7852606 )이 있었다. 하지만 과연 swift를 server-side에서 사용해서 얻는 이점이 무엇인가? 에 대한 대답은 여전히 의문인 것 같다. 결국 swift는 LLVM의 front-end 일뿐인 상황에서 Objective-C로 server-side를 구성하는 것과 차이가 없다는 것이 현재까지 느낀점이다. 또한 Core Foundation 레벨 API만을 이용하던지 Cocoa Foundation 레벨 API을 오픈소스로 공개하지 않으면 Server 환경도 OSX에 국한되기 때문에 비용적인 측면에서 단점이 될 것 같다. OSX나 iOS에 국한되어 Server-Side 사용법을 고민해본다면 좋은 방향이 이미 존재하고 있다고 보인다. Objective-Cloud ( http://objective-cloud.com ). iOS 앱내부에서도 서버를 띄울 수 있는 모듈이라고 볼 수 있을 것 같다. 혹은 Server-Side와 Client-Side 언어를 맞춘다는 의미에서는 차라리 RPC, API 인터페이스 수준의 빠른 구현을 제공하는 방향도 괜찮을 것 같다. 일단, 어떤 이점이 있는지는 계속 고민해봐야할 점으로 남겨둔다.
모델별로 번역 값들을 사용할 수 있다는 것인데... 문제는 꺼내오는 방법이 없음... http://stackoverflow.com/questions/5600558/localizing-core-data-model-properties-for-display/5600721#5600721 이런 삽질들이 나오고...
Core Data DB File 에 IO wait로 부하가 걸리는 경우 선택해볼 수 있는 방법
http://stackoverflow.com/questions/5231775/can-multiple-two-persistent-stores-be-used-with-one-object-model-while-mainta
http://commandshift.co.uk/blog/2013/06/06/multiple-persistent-stores-in-core-data/
1개의 DB Model을 가지고 여러개 sqlite로 분할 저장할 수 있는데
migration 시 model 충돌에 대한 대처법이 기존 대비 좋은 점이 없어서 적용은 다음 기회에 해봐야겠다.
아무튼 Fetched Properties 에 대해서도 알 수 있게된 좋은 경험이었다.
아쉽네…
으흠 그냥 "[dict respondsToSelector:NSSelectorFromString(@"autorelease")];" 이라고 쓰면 안되려나? 너무 생각이 짧았나? 또... __autoreleasing 를 명시적인지 암시적인지 고민꺼리... __autoreleasing가 항상 동작하는 것은 아니라고 하는데 어느 경우인지 정확이 다가오지는 않는다. 이렇게 쓰는 것 자체가 마음에 안든다고!
트위터에서 “개발자 구하는 법” 이라는 글을 보는데 말미에 이도저도 힘드니 그냥 급한대로 외주를 쓰라는 맥락의 글이 있었다. 반우스개 소리로 들었지만 진지하게, 개발외주를 써야할 때와 아닐 때는 정확히 언제인 것인가? 또 어떤 선택이 어떻게 유리한가?
외주 전문 일꾼으로 활동하는 분들은 여러 가지 앱의 형태를 구상하여 나름대로의 와꾸를 짜놓고 약간의 손질만 하면서 ‘원소스멀티유즈’ 전략을 쓰고 있다. 뭐 어느 정도 일을 하다보면 포트폴리오도 늘고, 찾아주는 사람도 많아질 것인데, 이쯤되면 본인이 일을 골라잡을 수도 있을...
서비스에서(내가 해본 것의 대부분이 서비스이기 때문에) 외주는 극히 피해야하는 항목이라고 본다. 기본적으로 아웃소싱의 개념은 모든 것을 외주를 주는 것이 아니라 핵심에 집중하기 위해 비핵심은 위임하는 것이다. 핵심 가치에 부합하는지가 아웃소싱과 인소싱를 가르는 기준이라고 볼 수 있다.
예를 들어 서비스는 인소싱, 서버 관리는 아웃소싱. 인터넷 뱅킹으로 본다면 모바일 은행거래가 핵심 가치에 부합하지 않다고 보는 것이다. 따라서 아웃소싱. 미국의 온라인거래 전문 은행(레퍼런스필요)은 모바일 은행거래가 핵심 가치에 부합하기 때문에 인소싱을 해야할 것으로 봐야한다.
마지막으로 비용적인 측면에서 아웃소싱을 찾는다면 기대하는 품질의 아웃소싱을 해주는 업체는 그리 많지 않다. 있다고 해도 생각 이상으로 꽤나 비용을 주어야 한다.
The one of the most difficult iOS programming is a variety topics of APIs.
서버, 특히 웹 개발자로 경력을 시작한 나에게 iOS 프로그램을 만들다보면 가끔씩 숨이 턱턱 막히는 경우가 생긴다.
지난주에는 Core Data에 대한 깊은 조사가 필요해서 온갖 API와 가이드 문서들을 헤집고 다녔다면, 이번주에는 네트워크 API 에 대해 싹 다 찾아 방법을 찾아야 하고 다음주에는 아마도 공통 UI 콤포넌트를 만들어야 하기 때문에 UIView 관련 객체를 해집고 다닐 것 같다.
웹에서는 결국 네트워크를 통해 전달해주고 전달받은 데이터를 중심으로 하나하나 뚫고 나가면 되었지만 OS 전반적으로 수정이 필요한 iOS 앱 개발에서는 너무 넓은 범위의 주제를 한꺼번에 다뤄야 해서 깊이 들어가려고 하는 내 성향에서는 한 건 한 건이 힘들고 막막한 작업이 되는 것 같다.
우리도 이번에 개편을 하면서 이전에는 NIB을 사용하지 않다가 NIB을 사용하기로 결정했다. Visual Tool로 UI를 만드는 것이 즉시성이 좋기 때문에 이점이 있으면서도 세밀한 조정이 힘들기 때문에 어려움을 겪기도 한다. 일단 기존 코드로 UI를 만드는 방식으로는 생산성이 너무 떨어지는 단점으로 대안이 필요했고 NIB을 극단적으로 사용해야봐야 중간지점을 찾을 수 있을 것 같아서 Autolayout 까지 사용하기로 결정했다. 몇개월 더 사용해보고 소감을 적어보는 글을 써봐야겠다.
Hyuk the Programmer @hyukhur - Tumblr Blog | Tumgag
jbbartram-illu
germansingergirl
kaledo-art
blakekathryn
andulkaphoto