지율 - 논스톱 지랄리스틱 마하3 대쉬

Cydia 실행하면 바로 종료되는 문제.

지이이이율 — Fri, 17 Jun 2011 11:20:23 +0900

증세

Cydia를 실행하면 즉시 종료 됨. 로그를 분석하면 크래시 정보가 보임.

원인

Cydia가 데이터 베이스를 업데이트 하던 도중, 강제 종료되거나, 아이폰이 재부팅 또는 전원을 잃음.

해결

/etc/apt/source.list.d 내의 모든 내용 삭제.

만약 SSH를 설치해 두지 않았거나 iFile과 같은 파일 관리 앱을 설치해 두지 않은경우, iPhoneExplorer또는 iFunBox를 이용할 것.

JB 했더니 멀쩡한 앱들이 아이폰 내 앱스토어에서 업데이트가 안될 때

지이이이율 — Fri, 17 Jun 2011 11:17:08 +0900

증세

아이폰에서 앱스토어에서 정상적으로 구매한 앱 및 무료앱들이 설치는 가능하지만 업데이트하려고 하면 "아이튠즈 스토어에 연결할 수 없음"이라는 에러 메시지가 뜸.

확인된 환경:

아이폰 3gs, iOS 4.3.1 탈옥

원인

Hackulo.us 에서 제공하는 AppSync가 특정 경우 설치 정보를 잘못 빌드 하는 것으로 추정.

해결

/var/mobile/Library/Caches/com.apple.mobile.installation.plist 삭제 후 재 부팅.

아이폰 게임 센터 오작동 문제 해결 방법

지이이이율 — Wed, 9 Feb 2011 22:04:43 +0900

증세

다음 중 하나 또는 복수:

게임 센터를 실행하면 친구가 모두 사라지고 없다.
"나" 라고 표시되어야 될 자리에 "Sand Box"라고 나온다.
기존 계정으로 로그인 하면, 새 계정을 만들라고 한다.
몇 번의 재시도 끝에, 친구 및 게임이 정상적으로 보이게끔 로그인 하더라도, 최근에 설치한 게임 센터를 이용하는 크랙된 게임을 실행하면, 다시 로그인하라고 나오며, 이 때 로그인하면, 또 다시 Sand Box 계정으로 로그인 된다.
크랙하지 않은 보통 게임은 게임 센터가 잘 작동한다.

원인

최근 업데이트 된 Installous 4.0은 AppSync 4.0+ (숫자는 이래도 AppSync 4.1과 AppSync 4.2보다 나중에 나온 최신 버전이다) 를 내장하고 있다. AppSync는 크랙된 아이폰 앱들을 설치 할 수 있도록 하고, 아이튠즈와 동기화 될 수 있도록 한다. 문제는 Hackulo.us의 마지막 업데이트 버전은, ipa파일들을 동기화 할 때 *개발자 디버그* 모드로 앱들을 설치한다는 데 있다. 이는 실수로 여겨지지만, 아직까지 공식적인 업데이트는 없다.

아이폰 앱이 개발자 모드로 실행되면, 내부에서 게임센터를 호출 할 때, 테스트 계정으로만 로그인 하게 되고, 따라서 실제 계정이 아닌, 샌드박스 계정으로만 로그인 된다.

해결책

가장 좋은 해결책은 게등위가 크랙 앱을 쓸 필요와 함께 사라지는 것이지만, 빠른 시일내에 이뤄지기는 어려울 것 같다.

예전 버전의 AppSync 및, Installous 4를 설치하여 이 문제를 해결 할 수 있다. 방법은 다음과 같다:

아이폰을 아이튠즈에서 백업한다. 각 앱의 문서나, 게임의 진행상태등을 잃지 않으려면 꼭 해야 한다.
아이폰을 순정상태로 복원한다.
green p0ison rc5_2이상 버전으로 JB 한다.
Cydia 에서 다음의 리포지터리를 추가한다:
http://sinfuliphonerepo.com
해당 리포지터리에서, 자신의 펌웨어 버전과 일치하는 AppSync를 설치한다. (4.1 또는 4.2)
해당 리포지터리에서, Installous 4를 설치한다.
아이튠즈에 연결해 백업된 데이터를 이용해 복원한다.

리소스

http://greenpois0n.com/
어떤 이유에서건 sinfuliphonerepo.com로 부터 구버전의 AppSync가 힘든 경우 이곳의 선구자가 남긴 포스트로 부터 다운 받아 수동으로 설치할 수 있다.

한계

애초 원인을 분석 한 뒤에, 최신 버전의 AppSync로 설치된 앱들만 지우고, AppSync를 언인스톨하고, 구버전의 AppSync를 설치 한 뒤, 다시 동기화 하면 문제가 없을 거라고 생각했지만, 아니었다. 귀찮더라고 복원. 고고.

블리자드 중계권 요구가 저작권에 따른 정당한 권리라고? 웃기지마라.

지이이이율 — Fri, 8 Oct 2010 16:32:41 +0900

마이클 길마틴은 "블리자드의 핵심 사업은 게임개발이며 창조적 결과물에 대해 권리를 주장하는 것은 당연한 일이다" 라는 뻔하고도 감정적인 말을 하며, 마치 중개권 = 저작권이라는 암시를 걸고 있다.

이 글은 많은 부분이 추후에 수정되었습니다.

팬들이 감동을 느끼고 손에 땀을 쥐고 선수를 사랑하는 것은 그들이 일궈내는 드라마지, 꼬물꼬물 움직이는 3d 그래픽과 까다로운 게임의 규칙따위가 아니다.

박지성이 공잡고 뛰는 거랑, 나 같이 평범한 사람이 공잡고 뛰는 것은 엄연히 다른 가치의 엔터테인먼트를 제공한다. 방송용 경기의 가치가 어디로부터 오는가의 문제를 먼저 논의 해야한다. 축구공의 발명가가 축구 경기에 대한 중개권을 요구하는 것은 사리에 맞지 않다. 바둑판과 바둑돌은 아주 만들기 쉽지만, 신의 한수를 두는 것은 어렵다. 이 둘은 *별개*의 문제다.

우리나라의 E스포츠 문화는 음지에서, 정말 어렵고 힘들게 고생한 프로게이머들과, ~~프로게이머 협회(알고 보니 이들은 별로 한게 없고 돈도 꿀꺽한듯 하다)~~, 그리고 우리들 하나하나의 팬쉽이 일궈낸 독창적인 결실이다. 블리자드는 그 한 부분을 차지할 뿐이다. 우리가 보고 싶어하는 것이 게임 화면이나 음향 그 자체는 아니다. 선수들이 만들어내는 게임의 내용을 뿐만아니라, 여러 요소들이 복합적으로 작용하는 게임 방송 컨텐츠에 대해, 블리자드는 독자적으로 중개권을 요구할만한 근거가 확실치 않다. 따라서 기소한다 하더라도 조사가 쉽지 않을 것이다.

블리자드도 바보가 아닌 이상 충분히 이 점을 인지하고 있을 것이다. 그럼에도 강경한 태도를 표명 하는 것은, 이 총합적 가치에서 비롯한 이득을 케스파에서 독점적으로 차지하면서도 운영도 건전치 않았기 때문에, 그것에 대한 정치적 시위로 볼수 있을 것 같다.

나는 멋진 경기의 내용이 게이머들로 부터 온다고 생각하기 때문에, 그들의 이익을 대표할 수 있는 단체가 게임 내용에 대한 저작권을 가져야 한다고 생각했다. 그러나 케스파는 그러한 기능을 올바로 수행하지 못하고 있는 것 같다.

그럼에도 내 생각은 여전히 변함이 없다. 중개권에 가격이 붙을 수 있다면, 경기 내용이 훌륭하기 때문이지 잘 만들어진 게임이기 때문이 아니다. 따라서 블리자드는 중개권을 행사해서는 아니된다. 블리자드의 중개권 행사를 정치적 시위로 해석한다면, 고개를 끄덕일 수 있지만, 이익논리에 따라 경기 내용에 대한 저작권을 주장하는 것이라면, 여전히 용서할 수 없다. 덜 나쁜 답을 답으로 고르자라는 의견에도 동조할 수 없다.

X-Wing 음함수!

지이이이율 — Wed, 29 Sep 2010 10:00:40 +0900

음함수

(x^2+y^2+z^2<0.2)+((y^2+z^2<0.08)*(x<0.4)*(x>0))+(x^2+4*y^2<(1-abs z)*0.12)+((abs z<0.95)*(abs z>0.9)*(abs x+abs y*0.3<1))+((abs z<1)*(abs z>0.89))*((abs x<0.7)*(abs y>0.9)+(abs y<0.035)+(x>y*0.7-0.05)*(x<y*0.7+0.05)+(-x>y*0.7-0.05)*(-x<y*0.7+0.05)+((abs x+abs y*0.3<1.05)*(abs x+abs y*0.3>0.95)))

결과

How to Brighten iChat Camera

지이이이율 — Mon, 27 Sep 2010 22:57:34 +0900

오래된 맥을 사용하다 보면, iSight의 센서 이상으로 아이챗이나 포토부스 등에서 카메라 영상이 굉장히 어둡게 나옵니다. P-Ram 리셋, 어플리케이션 재시작등을 이용해서 일시적으로 이문제를 해결할 수는 있지만, 궁극적으로는 새 맥을 지르거나 수리해야 합니다. 또한 이를 보정하는 소프트웨어도 있지만 유료입니다. 아이챗에 비디오 효과를 추가해서 이문제를 손쉽게 해결할 수 있지 않나하는 생각이 들어서 조사해보니, 쿼츠 콤포저는 매우 만들기 쉬운데다, 인스톨러도 만들기 어렵지 않아 후다닥 만들어 봤습니다.

ps. Snow Leoperd 에서만 작동합니다.

Download

iChat Brightener.zip

Uninstall

맥에 기본 포함된 무료 패키지 메이커는 언인스톨을 지원하지 않아서 수동으로 언인스톨 하셔야 합니다. 또한 모블미 인증서-ㅅ-로 서명했더니 에러가 나서, 이 인스톨러 패키지는 서명이 없습니다. 아마도 유료 개발자 프로그램에 딸려오는 인증서로만 제대로 된 서명이 될 것 같습니다.

/Library/Composition 폴더에서 bright, more-bright, most-bright 세 개의 파일을 지워줍니다.

그래프 예쁘게 그리기

지이이이율 — Mon, 9 Aug 2010 16:33:26 +0900

최근 관계형 데이터 베이스 디자인 도구를 만들고 있는 데, DB로 부터 역공학 된 DB의 모델을 우아하게 그려주는 문제를 담당하게 되었다. 이들(테이블과 관계선들)을 보기 좋게 배치하는 데 필요한 여러가지 관심사가 있는 데, 그중에 하나가 교차선 없이 공간 효율적으로 테이블들과 관계를 배치하는 문제이다.

교차된 선이 나타나지 않게끔 버텍스를 이동하는 아이폰용 퍼즐게임을 즐겨본적이 있어서, 이와 관련된 AI나 그래프 이론이 있을거라 생각해서 뒤져봤다.

그러나 이런 문제에 대한 알고리즘 연구가 이정도로 형편없다는 데 매우 놀랄 수 밖에 없었다. 주제를 명기하는 이름조차 제대로 없어서, Drawing Graphs Nicely 정도로 적당히 불리고 있었다. 아무튼 다음과 같은 요구 조건들이 달성되야 한다.

교차: 가능한한 교차되는 선이 나타나지 않아야 한다.
영역: 가능한한 적은 면적을 사용하여 배치해야 한다.
엣지 길이: 가능한한 엣지의 길이는 짧아야 하며, 장해물을 피해가야 한다.
비율: 주어진 비율에 대해 최적화된 배치를 이뤄야 한다. (어느 용지에 출력할 것이냐 등등의 문제)

불행하게도 이 Goal들은 서로 배타적이지 못하고, 모순을 이루기도 한다. 더더군다나 교차등과 같은 문제는 NP 컴플릿 문제를 발생시키기도 한다.

수학적 연구가 제대로 진행되지 않은 탓에, 이것에 대해 최적해나, 성능 기반의 유사해를 내 놓는 접근 방식은 사용할 수 없을 것 같고 - 개발자로서는 도저히 이 무시무시한 시도를 엄두조차 낼 수 없다 - , 장력 시뮬레이션등과 같은 - 스프링 레이아웃과 같은 - 방법이나 뽕빨 휴리스틱을 써야 할 것 같다.

30년간 아무런 진전도 보이지 못한 인공지능 분야의 몰락은 참 아쉬운 일이다. 에라이. 하긴 뭐 돈 안되니깐. 인정.

모든 것을 MAC으로

지이이이율 — Mon, 2 Aug 2010 23:35:19 +0900

이 매뉴얼을 처음 손에 잡았을 때, 내가 왜 저 말을 무시했을까.

- 지율, 모블미를 결재하며

아이폰 앱 개발시 코어 데이터 도입 타당성

지이이이율 — Mon, 2 Aug 2010 22:49:09 +0900

얻을수 있는 장점들:

SQLite로 고속 동작을 보증하는 추상화 모델 클래스를 제공 받을 수 있다. (모델 파일을 더블 클릭하여 새 윈도우에서 엔티티 디자이너를 연상태에서만 새 파일 마법사에 "Managed Object" 항목으로 나온다 - 버그인지 의도인지 모르겠다, 개발자가 부분적으로 오버라이딩 한 경우 머지는 안된다.)
코어 데이터로 추상화된 모델은 모델이 버전업 했을 경우 매핑 모델을 정의함으로써 데이터 버전업 기능을 쉽게 구현할 수 있다.
코어 데이터로 추상화된 모델은 WIFI, Bluetooth등으로 싱크할 때 더 편리한 API지원을 받을 수 있다.
데이터 정합성을 어느정도 보장 받을 수 있다. (관계형 DB에서 삭제 액션 등등)
이미 존재하는 클래스로 부터도 모델 엔티티 다이어그램을 얻을 수 있다. (하지만 역반영은 불가능하다)

이제부터는 깐다. :)

효율적인 디자인 - 모델 매핑 부재:

맥에서의 개발과는 달리 아이폰, 아이패드에서는 이 코어 데이터와 UI 가 모델 패스로 바인딩 되지는 않는다. 그러나 XIB파일을 일반 xml에디터로 열어 실험해 본 결과, 모델 바인딩이 된다고는 한다. 키밸류 코딩을 이용하면 코드로는 바인딩이 가능한 것이 확실하다. 그러나 이 부분에 대해 애플이 공식적인 지원이 보증될 지는 알 수 없고, 리젝션 위험도 있다.

학습 비용에 대한 리스크:

코어 데이터는 모델로서의 기능 보다 DB Row로서의 특징이 훨씬 강하기 때문에, SQLite 에 대한 이해를 필요로 하며, 동시에 키밸류 코딩 및 옵저빙을 세션 매니저로 활용하므로 Object-C에 대한 깊은 조예를 필요로한다. 따라서 다분야의 전문지식을 갖춘 MDA경험자가 필요하며, 이는 단순하게 교육되거나 커리큘럼에 의해 학습되기 어렵다. 이미 MDA에 익숙한 고급 엔지니어가 아이폰과 같은 초급 기술을 다시 습득하기위해 시간을 투자하는 것은 비용낭비로 비춰지기 쉽기 때문에, 정치적 요건 마련이 필요하다. 또한 이것은 시니어 엔지니어의 작업부담을 높여, 효율적인 분업을 어렵게 할 것이다.

모델 유연성 리스크:

EMF나 기타 모델 제네레이션 프레임웍과 달리, XCode의 모델 클래스 생성기능은 매우 초보적인 수준이어서, 새 파일 만들기만 가능하다. 따라서, 모델 생성 후 후처리 작업에 대한 프로세스를 수동으로 관리해야 하며, 인건비 상승요인이 된다. 또한 모델의 동작 방식은 키밸류 매커니즘에 의해 관리되기 때문에, 단순히 유도속성 하나를 추가하는데에도 최고 수준의 엔지니어가 필요하며, 모델이 리팩토링 될 때마다 투입되어야 한다.

임시 결론:

엔터프라이즈 B2B 에서 엔티티 디자이너는 절실히 필요하지만, SQLite같은 낮은 스케일과 연결된 엔티티를 사용할 수는 없을 것이다. 물론, ManagedObject는 너무 단순하기 때문에 다른 스토어링 코디네이터나, 컨텍스트를 직접개발하는 것이 어려울 것으로 보이지는 않는다. 코어 도큐먼트는 오랜동안 맥의 앱들에서 신뢰성이 확보되었고, 엑스코드 및 아이폰 SDK의 흐름을 보면, 애플이 점점 더 코어 도큐먼트의 지원을 확장하고 있으므로, 여유자금이 충분하다면, 이에 기반한 작업 프로세스를 갖춰 놓는 것도 좋을 것 같다.

그러나 아이폰 앱의 수익구조를 살펴볼 때, 이러한 다분야 전문가를 몇명이나 고용할 수 있을지는 의문이다. 이러한 고민은 자바 진영 쪽엔 밤하늘에 육안으로 관찰 가능한 별의 수만큼이나 많은 논의와 발전이 있어왔기 때문에, 안드로이드에서 MDA를 도입하는 것은 너무나 쉬운 일이다. 때문에 B2B프로젝트에서 아이폰 개발이 생산성 측면에서 불리할 것 같다. 또한 B2B환경에 작용하는 삼성과 같은 기업의 압력 및 협력 체계 또한 무시할 수 없다.

그럼에도 B2C프로젝트에서 블루투스, 아이튠즈, 와이파이등을 이용한 사용자 데이터 싱크 기능은 사랑받을 것이 분명하고, 코어 도큐먼트를 사용하면 그러한 기능에 대해 빠르게 대처할 수 있다. 하지만 아직까지는 사용자의 데이터를 매우 중요시하여, 그것을 다루는 것이 중점이 된 비즈니스 앱은 많지 않고, 현재 수익이 높은 앱들은 대부분 그러한 특성을 갖고 있지도 않기 때문에, 코어 도큐먼트의 도입은 비용증가에만 머물 우려도 있다. 이러한 특성은 사용자의 눈에 한 두번만에 들어오는 것이 아니기 때문에 가치를 입증받기도 쉽지 않다. 충분한 능력이 있다면 도입할만한 가치나 근거는 분명히 있다. 여러모로 생산성이 뛰어나 질 것이며, 향후 작성할 앱들의 기본적인 품질을 높혀줄 것이다.

소프트웨어가 망하는 과정, 아키텍트 VS 구현자들

지이이이율 — Mon, 26 Jul 2010 21:26:24 +0900

기획자는 자신이 설계한 아키텍트에 대해 매료되며 그것을 요람처럼 받드는 경향이 있다. 이것은 그 기획자가 개성과 창의성을 유지하는데 있어서는 필요한 덕목이다.

하지만, 그 아키텍트의 결함과 논리적 모순을 찾아내는 것은 언제나 구현자들이다. 왜냐하면 대부분의 아키텍트는 구현영역의 아주 간단한 기초지식 조차 없이 설계하는 경우가 많기 때문이다. 대부분의 소프트웨어 기획자들은 모니터 화면에 점 하나가 어떻게 찍히는지조차 모르며, 또 그것을 그다지 부끄럽게 여기지도 않는다. 따라서 구현자들은 그 기획을 실행하거나, 그 이전 단계에 이르러서야 문제를 찾아낸다.

구현자가 그러한 결함이나 모순을 지적하면, 아름다운 아키텍트에 대한 부정행위를 곧 신성모독으로 인식하며, 해당 엔지니어는 무능한 엔지니어라는 오명을 쓰게 된다. 대화가 통하지 않는다는 사실을 알게된 구현자는 어떻게든 그 문제를 자기선에서 처리한다. 이 때, 제품의 형상은 1차적으로 기획의도를 벗어나게 되고, 더 이상 구현자들은 아키텍트를 따르지 않으며, 직속상관만을 따르기 시작한다.

가령, 기획자가 실내에서도 위치 서비스가 가능하다면, 대형 마트에서 물건을 찾아서 바로 카트에 실을 수 있어 유용할 것이라는 아이디어를 낸다. 그리고, 엔지니어들에게, 마트 내부에 모의 GPS위성을 설치하여, 위치를 특정할 수 있는 솔루션을 개발하라고 한다.

그러나 엔지니어들이 조사한 결과에 따르면, GPS는 최소 3대이상의 위치가 알려진 정지점에서 각각의 거리값을 이용해, 3개의 구가 만나는 교점을 계산하는 방식이란 것을 알게된다. 마트의 내부엔 어마어마하게 많은 양의 장해물이 있기 때문에, 산란전파로 인해, 방정식이 흩트러져 그것을 계산하는 것이 어렵다는 사실상 불가능하다고 보고한다. 기획자는 GPS의 작동원리를 제대로 이해하려는 시도를 하지 않고, 차량도 건물들이 복잡하게 늘어서 있어도 GPS가 작동된다는 점을 예를 들어, 순전히 자신의 직관에 기초하여 반박한다. 우주의 인공위성은 충분히 멀리 떨어져 있기 때문에 오차가 무시할만한 수준이지만, 실내에서 그렇지 않다는 사실을, 수학자나 물리학자가 아닌 소프트웨어 엔지니어가 정확히 말할 수 있을리 없으므로, 엔지니어는 논쟁에서 패배하게 된다. 대부분의 엔지니어는 훌륭한 정치가가 아니다.

엔지니어들은 무선 AP그리드라던지 다른 대안들을 검토하여, 그것을 어떻게든 구현해낸다. 이때 사실 수학자나 물리학자들의 도움이 필요하지만, 예산문제로 철회되어 엔지니어들이 도메인 문제를 스스로 푼다.

디자인이 반영될 시점, 기획자는 디자이너를 싸게 시간제로 고용하여 작업한다. 얼결에 프로젝트 마지막에 투입된 디자이너는, 시스템의 개요나 컨셉에 대한 아이디어가 없으므로, 추상성이 매우 떨어진 아이콘이나, 그냥 보기에만 좋은 아이콘들을 기계적으로 찍어낸다. 엔지니어들은 전속 디자이너가 필요하다고 강조하지만, 기획자가 프로젝트 기간내내 거의 아무일도 하지 않고 앉아서 구경만 하는 아티스트에게 돈을 지불할 생각을 갖게 만드는 것은 매우 어렵다.

도저히 디자인 산출물을 사용할 수 없다고 판단한 엔지니어들은 직접 아이콘을 그리기 시작하며, 불만을 축적한다. 결국 기획의도와 전혀 다른 괴물이 태어난다. 운이 좋아 이것이 성공하더라도, 구현자들이 공로를 인정받는 경우는 극히 드물며, 기획자는 제품의 실제 형상을 완벽히 오해하고 있는 상태가 된다. 이 때, 지친 구현자가 직장을 그만두게 되면, 더 이상 이 시스템은 아무도 손을 쓸 수 없게 되고, 완벽한 실패로 다가가게 된다.