1. 애플/아이폰의 개발/유통 관련 리소스와 프로세스는 정말 튼실하게 잘돼있다. 막상 겪어보니 명불허전. 

2. 만드는 과정에서 베타 버젼 상태의 라이브러리를 사용했다가 최종단계에서 오류 때문에 포기하고 처음부터 다시 만들기를 2번이나 반복했다. 내가 무언가를 제조해보니, '제조업체'입장에서 생산과정에 사용되는 소재/기계의 안정성과 신뢰성은 정말 중요할 수 밖에 없음을 느끼게 됐다.  레퍼런스가 튼실한 B2B업체가 왜 그리 높은 마진으로 롱런하는지 잘 알게 됐다. 

3. 당연한 얘기지만, 초기에 완성도있는 계획을 갖고 일을 시작하는 것이 중요하다. 취미로 시작한 일이 점점 커지면서 꼬여갈 때의 그 난감함이란;; Robust한 구조를 실제 생산 이전에 머릿속에서 그려낼 수 있는 능력은 모든 생산활동에서 정말로 중요하다. 어쩌면 효율성이란건 처음부터 정해져 있는지 모른다. 



하루에 조금씩 작업하면서, 거의 1년간 만들어왔던 아이폰용 전자공시 앱이
마침내 앱스토어에 등록됐습니다. 

앱스토어 링크 : http://itunes.apple.com/us/app/id439676064?mt=8&ls=1



아이폰에서 금융감독원 전자공시(DART)를 조회할 수 있게 하는 앱입니다. 
전자공시는 투자자와 금융인에게 필수적인 정보임에도 불구하고, 금융감독원 전자공시 홈페이지가 스마트폰에서 제대로 동작하지 않아 외부에서 공시를 확인할 수 없었습니다. 

저 역시 직업상 스마트폰에서의 전자공시 이용을 갈망하다가 이번에 모바일 전자공시 앱을 직접 만들게 되었습니다. 
이제 언제 어디에서나 터치만으로 공시를 볼 수 있습니다! 


## 주요기능(Features) 

1. 상장법인/기타법인의 모든 공시 내용을 조회/열람할 수 있습니다. 

2. 기업검색시 KOSPI/KOSDAQ/기타법인을 선택적으로 조회할 수 있습니다. 

3. 최근공시 조회 기능 지원합니다. 

4. 최근공시 조회시, 상장법인의 실적 관련 공시만을 필터링하는 기능을 제공합니다. 중요 공시를 누구보다 빠르게 즉시 확인할 수 있습니다. 


손안의 모바일 공시로, 중요 정보를 놓치지 마십시오! 






앱에 대한 문의사항은 개발자의 블로그(http://kang.dk/)를 통해서 이뤄집니다. 



엑셀에서 VBA를 하다보면, 실행속도가 엄청나게 느려지는 경우가 발생한다. 
그 동안 속도 빠르게 해본답시고 이런저런 스파게티 코드를 짜고 있었는데.. 이런 심플하고 간단한 방법이...아 ㅠㅠ
코드가 들어갈 자리 위아래로 다음과 같은 코드를 넣어주면 된다. 

Application.ScreenUpdating = False   '코드 실행 중 차트와 같은 화면 업데이트 방지

Application.Calculation = xlCalculationManual   '코드 실행 중 셀 계산 방지

Application.EnableEvents = False   '이벤트 실행 방지

(코드가 들어갈 자리)

Application.EnableEvents = True

Application.Calculation = xlCalculationAutomatic

Application.ScreenUpdating = True

TAG VBA

애플이 왜 아이폰(혹은 아이패드)에서 플래시 사용을 허용하지 않는지에 대해서,
스티브 잡스가 어제 직접 긴 글을 남겼다. 워낙 잘 쓴 글이라 내용을 곱씹어 보는 차원에서 원문그대로 번역해 포스팅 해본다.

------------------------------

애플은 어도비와 오랜 관계를 유지해왔다. 사실, 우리가 어도비의 창업자를 처음 만난 것은 그들이 창고에서 사업을 막 시작할 때 부터였다. 애플은 어도비의 첫 대형 고객이었고, 우리의 신형 레이저 프린터에 그들의 포스트스크립트 랭기지를 도입했다. 애플은 오랫동안 어도비의 지분을 20% 가까이 갖고 있었다. 두 회사는 DTP산업의 개척을 위해 긴밀하게 협력했었다. 황금 시기 이후, 회사는 서로 각자의 길을 갔다. 애플이 거의 망할 뻔했었던 위기를 지나는 동안 어도비는 어크로뱃 제품을 통해서 기업시장으로 진입했다. 오늘날, 두 회사는 두 회사의 공통된 고객들을 위해 협업하고 있다. (어도비 제품 판매의 거의 절반을 맥 유저들이 차지하고 있다.) 하지만, 공통된 이해관계 이상의 것도 있다. 

고객들과 평론가들이 우리가 아이폰에서 플래시를 허용하지 않는 이유를 보다 잘 이해할 수 있도록, 몇 가지 생각을 얘기해 보겠다. 어도비는 우리의 결정을 순전히 비즈니스적인 결단으로 윤색하고 있다. (우리가 앱스토어를 보호하고 싶어 한다고 말이다.) 하지만, 실질적으로 플래시 허용문제는 기술적인 문제다. 어도비는 우리가 폐쇄적인 시스템을 사용하고, 플래시는 개방돼있다고 말한다. 하지만, 진실은 그 반대이다. 

먼저, 개방성에 대해서 얘기해보자. 

플래시는 100% 어도비의 전유뮬이다. 어도비를 통해서만 서비스되고, 향후 기능개선 여부, 가격 등도 모두 어도비가 결정한다. 플래시가 광범위하게 사용되고 있긴 하지만, 이것이 플래시가 개방적이라는 것을 의미하지는 않는다. 어떤 관점에서 보든 플래시는 폐쇄적 시스템이다.

애플 역시 많은 '100% 전유'의 시스템을 갖고 있다. 아이폰/아이패드의 OS가 그렇다. 하지만, 우리는 웹에 대한 표준에 있어서만큼 개방적이어야 한다고 굳게 믿는다. 플래시를 도입하는 대신 우리는 HTML5, CSS, JavaScript를 적용했다. 모두 개방적 시스템이다. 애플의 모바일 디바이스는 이 기술을 바탕으로 높은 퍼포먼스와 낮은 배터리 사용량을 보인다. 애플과 구글등이 도입하고 있는 HTML5를 통해서 개발자들은 플래시와 같은 써드파티 플러그인 없이도 복잡한 그래픽 효과를 가진 컨텐츠를 만들어 낼 수 있다. HTML5는 애플이 회원으로 있는 국제 위원회에 의해서 통제되는 개방된 플랫폼이다. 

또한, 애플은 웹을 위한 개방화된 플랫폼을 스스로 창조하고 공개하기도 한다. 예를 들어, 애플은 '웹킷'이라는 오픈소스 브라우저엔진을 만들었다. 구글이 웹킷을 사용해서 앤드로이드용 브라우저를 만들었고, 팜도 쓰고 있고 노키아도 쓰고 있다. 블랙베리의 RIM역시 향후 웹킷을 쓰겠다고 공표했다. 마이크로소프트를 제외하고 거의 모든 모바일 웹브라우저가 웹킷을 사용한다. 웹킷 테크놀러지를 개방화함으로써 애플은 모바일 웹 브라우저의 표준을 만들었다. 

두번째는 웹에 대한 완전한 접근성의 문제이다. 

어도비는 아이폰이 플래시를 쓰지 않기 때문에, 웹상의 존재하는 비디오 중 75%에 접근하지 못한다고 반복적으로 말해왔다. 하지만, 수많은 비디오들은 H.264라는 현대적 포맷으로 존재한다는 사실은 일부러 말하지 않는 것 같다. 전세계 웹 비디오의 40%를 차지하는 유튜브 동영상이 아이폰과 아이패드에서 아무런 문제없이 돌아간다. 비베오, 넷플릭스, 페이스북 등 수많은 컨텐츠들 역시 마찬가지다. 

또 다른 어도비의 주장은 플래시 게임을 돌리지 못한 것이다. 맞는 말이다. 하지만, 우리 앱스토어에는 다행히도 5만개가 넘는 게임이 있다. 전세계 그 어떤 플랫폼보다 많은 게임과 엔터테민먼트 앱들이 아이폰과 아이패드를 위해 존재하고 있다. 

세번째는 신뢰성, 보안, 퍼포먼스의 문제이다. 

시맨텍은 최근 플래시가 2009년 최악의 정보보안 기록을 갖고 있다고 강조했다. 우리는 플래시가 맥 컴퓨터에서 오류가 발생하는 가장 주된 원인임을 알고 있다. 이 문제를 해결하기 위해 어도비와 협력하고 있지만 이러한 문제들은 수년째 지속되고 있다. 우리는 아이폰,아이패드의 신뢰성과 보안성을 훼손하고 싶지 않다. 

더불어, 플래시는 모바일 기기에서 제대로 작동하지 않는다. 우리는 반복적으로 어도비에게 플래시의 퍼포먼스 개선을 요구했지만 아직 어떤 성과도 보지 못했다. 어도비는 스마트폰에 2009년 상반기부터 플래시가 탑재될 것이라 얘기했다가, 2009년 하반기라 얘기했고, 다시 2010년 상반기로 이제는 2010년 하반기로 또 말을 바꾸었다. 언젠가는 탑재가 되겠지만, 퍼포먼스가 어떨지 어떻게 알겠는가?

네번째는 배터리 수명 문제이다. 

비디오 재생시 배터리 수명을 보장하기 위해서, 모바일 기기는 비디오 디코딩을 하드웨어 적으로 처리해야 한다. 소프트웨적 디코팅은 너무 많은 전력소모를 불러온다. 현재 사용되는 많은 칩들이 H.264라는 하드웨어 디코딩을 지원한다. (블루레이 플레이어와 애플, 구글 유튜브, 비메오, 넷플릭스 등 수많은 회사들이 지원하는 규격이다.)

플래시가 최든 H.264를 지원하겠다고 발표했지만, 거의 모든 플래시 웹사이트의 비디오들은 현대의 칩들이 지원하지 않는, 소프트웨어적 디코딩이 필요한 구세대의 기술을 요구한다. 그 차이는 충격적이다. 아이폰에서 H.264비디오는 10시간까지 재생가능하지만, 소프트웨어 디코딩을 하면 5시간 이전에 배터리가 방전된다. 

웹사이트가 그들의 비디오를 H.264로 재인코딩할 때, 그들은 플래시를 전혀 사용하지 않을 수 있다. 플러그인 없이 사파리나 크롬 그리고 아이폰 아이패드에서 모두 잘 돌아간다. 

다섯번째는 터치 인터페이스의 문제다. 

플래시는 PC와 마우스를 위해 디자인됐다. 터치스크린과 손가락을 위한 도구는 아니다. 수많은 플래시 웹사이트들을 롤오버(커서를 가져갔을 때 반응하는 메뉴나 광고같은 것들)에 기반해 디자인됐다. 애플의 혁신적인 멀티터치는 마우스를 사용하지 않고 따라서 롤오버와 같은 컨셉은 없다. 손가락 터치를 지원하기 위해서는 많은 플래시 웹사이트가 새로 디자인돼야 한다. 개발자들이 새로 사이트를 만들어야 한다면, HTML5와 같은 현대적인 기술을 사용하지 않을 이유가 없지 않은가?

아이폰이 플래시를 구동한다고 해서, 이런 문제들이 해결되는 건 아니다. 

여섯번째는 가장 중요한 이유다.

플래시가 폐쇠적이고, 기술적인 단점들이 있고, 터치를 지원하지 않는다는 것을 넘어서, 플래시를 지원하지 않는 매우 중요한 문제가 있다. 
우리는 고통스러운 경험을 통해서, 플랫폼과 개발자 사이에 써드파티 소프트웨어 개입될 경우 궁극적으로 질낮은 앱들이 양산되고 플랫폼의 개선을 방해한다는 것을 알았다. 개발자들이 서스파티 라이브러리와 저작도구를 사용한다면, 플랫폼에 새로운 기능이 추가됐을 때 서드파티 제공자가 이를 지원하지 않는한 이 기능을 전혀 사용할 수 없게 된다. 우리 플랫폼의 개선 여부를 써드파티 개발자가 결정하도록 만들 자비는 우리에게 없다. 

이 문제는 서드파티 제공자가 크로스 플랫폼(플랫폼간 호환성)을 지향할 때 더 심각해진다. 써드파티 개발자는 그들이 지원하는 모든 플랫폼에 특정 기능이 도입되기 전까지는 그 기능을 지원하지 않을 것이기 때문이다. 결과적으로 개발자들은 모든 플랫폼의 가장 기본적인 기능들만을 갖고 앱을 개발해야 한다. 다시 말하자면, 다른 플랫폼에서 지원하지 않는 다는 이유로 우리의 혁신과 개선으로부터 개발자들을 유리시키는 것을 용납할 수 없다. 

플래시는 크로스 플랫폼 개발도구이다. 아이폰에 최적화된 앱 개발을 지원하는 건 어도비의 목적이 아니다. 모든 모바일 디바이스에서 사용가능한 앱을 만드는게 그들의 목적이다. 그리고 어도비는 애플의 플랫폼 개선에 아주 느린 반응을 그동안 보여왔다. 예를 들어, 맥 OSX가 도입된지 거의 10년이 됐지만, 애플이 이를 완전히 지원한 것은 고작 2주 전부터이다. 어도비는 맥OSX를 가장 마지막으로 완전히 지원한 서드파티 개발자이다.

우리 동기는 단순하다. 우리는 가장 지본되고 혁신적인 플랫폼을 개발자들에게 제공하길 원한다. 우리는 개발자들이 우리 플랫폼을 딛고 이제까지 없었던 최고의 앱들을 만들어 내길 바란다. 우리는 개발자들이 좀더 놀랍고 파워풀하고 유용한 앱들을 개발하도록 우리의 플랫폼을 지속적으로 개선시켜 나갈 것이다. 우리는 이 앱들을 기반으로 더 많은 단말기를 팔고, 개발자들은 보다 넓은 사용자 기반을 갖게 되고, 사용자들은 더 많은 기능들을 향유하게 된다. 모두가 승자되는 것이다. 

결론.

플래시는 PC시대의 유산이다. 플래시는 어도비에게는 무척 성공적인 비즈니스였고, 우리는 그들이 왜 모바일에 플래시를 적용하려 하는지 이해한다. 하지만 모바일 시대는 저전력과 터치, 그리고 개방화된 웹 표준의 시대이다. 모든 영역에서 플래시는 부족하다.

애플의 모바일 기기를 위해 쏟아져 나오는 미디어 콘텐츠들이 플래시가 더 이상 모바일 세계에서 필요치 않다는 것을 증명해주고 있다. 앱스토어의 20만개 앱들은 수만명의 개발자가 게임을 비롯해 풍부한 그래픽 효과를 가진 앱을 개발하는데 플래시를 필요로 하지 않는다는 것을 보여주고 있다. 

아마도 어도비는 과거에서 벗어나 앞으로 나아가고 있는 애플을 비판하기 보다는 HTML5와 같은 새로운 규격에 맞는 툴들을 개발하는데 집중해야 할 것이다. 


Steve Jobs
April, 2010

서버 구축할 일도 있고, 귀찮은 과정에 대한 정리차원에서..


OS는 Ubuntu 10.04 LTS의 서버버젼을 사용했다.
설치는 순식간에 끝난다. 엔터만 쭉 치면 된다.

최초 재부팅 후, 서버에 로그인 한 뒤, 
sudo apt-get update
sudo apt-get upgrade
상기 명령어로 시스템을 업그레이드 시킨다.

sudo apt-get install ruby ri rdoc irb -y
ruby 패키치를 설치한다. 과거에 괜히 최신버젼 설치한답시고, 1.9 설치했다가 피본 경험이 있으므로 --;; 얌전하게 기본 패키지로 설치한다. 

sudo apt-get install rubygems
rubygems도 설치해 준다. 우분투의 패키지 서비스 덕분에, 더 이상 컴파일 같은 작업은 없다.  
sudo apt-get install apache2 apache2-mpm-prefork apache2-prefork-dev -y
sudo apt-get install mysql-server mysql-client libmysql-ruby libmysqlclient15-dev
mysql 설치치 루드 암호 설정하는 부분이 있다.

루비 컴파일 관련 파일들을 깔아준다.
sudo apt-get install ruby-dev install build-essential libapr1-dev -y
sudo apt-get install libopenssl-ruby
이제 apt-get이 할 일은 끝났다.
sudo gem install rails --no-rdoc --no-ri
sudo gem install ruby-mysql passenger rake --no-rdoc --no-ri
레일즈 구동에 필요한 젬들을 설치한다. 쓸일없는 rdoc과 ri는 없앤다. 
sudo gem install mysql subdomain-fu gdata gd2 rack --no-rdoc --no-ri
개인적으로 좋아하는 gem들 깔아준다.

sudo /var/lib/gems/1.8/bin/passenger-install-apache2-module
passenger를 설정한다. 엔터계속 눌러주면,
LoadModule passenger_module /var/lib/gems/1.8/gems/passenger-2.2.11/ext/apache2/mod_passenger.so
PassengerRoot /var/lib/gems/1.8/gems/passenger-2.2.11
PassengerRuby /usr/bin/ruby1.8
위 내용을 아파치 설정에 넣어주라고 나온다. /etc/apache2/apache2.conf 파일을 열어 마지막에 해당 내용을 추가해주면 된다.

이제 세팅은 끝났다.
apache virtualhost 세팅만 잘 잡아주고
/etc/init.d/apache2 restart
이 명령어만 돌리면 잘 돌아간다. 

부가적으로, Mysql 서버의 UTF8  설정을 해줘야 한다. 
/etc/mysql/my.cnf를 다음과 같이 수정하고, sudo service mysql restart를 해준다. 

[client]
default-character-set = utf8

[mysqld]
# charset
default-character-set=utf8
default-collation=utf8_general_ci
init_connect=SET collation_connection=utf8_gerneral_ci
init_connect=SET NAMES utf8
character-set-server=utf8
collation-server=utf8_general_ci
character-set-client-handshake = TRUE

[mysqldump]
default-character-set = utf8

[mysql]
default-character-set = utf8



구글 검색해가며 삽질하는데 질려버리겠다. 기초없이 야매로 하려니 모든 것이 삽질이다.
서브도메인을 인식해서 라우팅하는 것을 구현하는데 두 시간 걸렸다. 이 간단한 것을;;

먼저 Subdomain_fu라는 gem 설치가 필요하다. 
플러그인 설치도 된다는데, 내 경우엔 안됐다.

gem install subdomain-fu

이 gem을 인스톨하고 나면 routes.rb에서 :subdomain이라는 조건을 붙일 수 있다.
실행하기 전에 config.gem 'subdomain-fu'을 environments.rb initializer안에 추가해준다 .

즉, routes.rb에,

map.with_options :conditions => {:subdomain => /.+/ } do |blah|
    blah.connect ':action/:id', :controller => "blah"
end

이렇게 넣어주면,

subdomain.aaa.com으로 접속할 경우,  blah라는 콘트롤러로 라우팅해준다. 
똑똑한 젬이어서,  www로 접속할 경우, 서브도메인이 없는 것으로 처리해준다. 

단, 실행환경이 devlopment이거나, test일 경우, 
subdomain.aaa.com에서 서브도메인을 subdomain.aaa로 인식하게 되는 문제가 있다. (localhost로 접근할 때를 대비해서 만든 것 같다)

개발/테스트 환경에서도 노멀한 서브도메인 인식을 하려면,

environments.rb에
SubdomainFu.tld_sizes = {:development => 1, :test => 1, :production => 1}
이 부분을 넣어주면 된다 .


subdomain_fu는 이것 외에도 기능이 많다.
콘트롤러나 뷰에서 아래와 같이 사용할 수 있다.

url_for(:controller => "my_controller",
          :action => "my_action",
          :subdomain => "awesome") # => http://awesome.intridea.com/my_controller/my_action
  users_path(:subdomain => "fun") # => http://fun.intridea.com/users
  users_path(:subdomain => false) # => /users
 users_url(:subdomain => false)  # => http://intridea.com/users

그동안 해온 초삽질의 완결판이라고 할 수 있겠다...한글문제 때문에 버린 시간이 그저 아깝기만 할 따름이다.

ruby 1.9 이상의 버젼에서 UTF-8 환경의 rails를 사용하려면 다음 3가지가 반드시 충족돼야 한다.

1. mysql을 연결할 때, "mysql"이 아닌 "ruby-mysql" gem을 설치해야 한다.
죽, gem install mysql하지 말고, gem install ruby-mysql 하라는 얘기다. 

2. rails는 반드시 2.3.5 이상의 버젼을 설치한다. 

3. 소스 코딩할 때 콘트롤러 rb파일 앞부분에 반드시 
# coding : utf-8
이 한 줄을 추가한다.

이상의 3가지를 하면, 디비에 한글이 들어가있던 erb template에 한글이 들어가 있건 관계없다 다 잘된다.
대부분의 뻘짓이 출발하는 이유는 관행대로, mysql gem을 설치하기 때문이다. 나도 이것때문에 며칠을 날렸다. 바보처럼 ㅠㅠ

그러나, 이 상황에서도 문제가 생긴다. 

erb파일에서 <%= link to %>같은 helper를 사용할 때,
helper 메소드의 파라미터에다가 한글을 집어넣으면 또 인코딩 문제가 발생한다. 

이 상황에서는 방법이 없다. 직접 actionpack소스 코드를 손봐야 한다.

액션팩에서 액션뷰가 설치된 디렉토리로 간다. (보통의 리눅스 서버라면, /var/lib/gems/1.9.1/gems/actionpack-2.3.5/lib/action_view가 될 것이다. )

거기 가면, renderable.rb라고 있다. 이 파일을 직접 손봐야 한다.

source = <<-end_src
          def #{render_symbol}(local_assigns)
            old_output_buffer = output_buffer;#{locals_code};#{compiled_source}
          ensure
            self.output_buffer = old_output_buffer
          end
        end_src
        
        begin
          ActionView::Base::CompiledTemplates.module_eval(source, filename, 0)
        rescue Errno::ENOENT => e
 이 부분을 찾아서,

source = <<-end_src
          def #{render_symbol}(local_assigns)
            old_output_buffer = output_buffer;#{locals_code};#{compiled_source}
          ensure
            self.output_buffer = old_output_buffer
          end
        end_src
source.force_encoding('utf-8') if '1.9'.respond_to?(:force_encoding)
 begin
          ActionView::Base::CompiledTemplates.module_eval(source, filename, 0)
        rescue Errno::ENOENT => e

빨간색으로 색칠한 한 줄을 추가하면 된다. 
아파치+패신저 환경이라면 서버를 재실행 해줘야 한다. 

이렇게까지 하면, 
ruby 1.9.1 + rails 2.3.5 + mysql 5 환경에서 한글을 사용하는데 문제가 없게 된다.

rails 3에서도 유사한 문제가 있는 것으로 알고 있으니 내 환경보다 상위 버젼을 사용하는 분들에게도 적용될 것 같다. 

취미로 하는 웹개발에 너무나 많은 정열을 쏟는 요즘이다 ㅠㅠ


2010. 4. 27 추가 내용

send_data명령어를 사용할 때 binary field에서 argument error가 나타나는 문제가 있다.
한글문제는 아니고... ruby 1.9와 rails 2.3.5의 인코딩 문제다. 젬을 또 수정했다.

/var/lib/gems/1.9.1/gems/activesupport-2.3.5/lib/active_support/core_ext/object/blank.rb에서

class String #:nodoc:
  def blank?
begin
    self !~ /\S/
rescue
        false
end
  end
end

위와 같이 수정했다. 삽질은 끝도 없구나.