이 글은 한글깨짐을 해결하기 위해서라기 보다는 문제를 해결하는 방식에 대한 정리를 위해서 입니다.
기술적인 내용은 링크한 내용들을 참고하시면 보다 많은 정보를 얻을 수 있습니다.

저는 업무에서 기술적인 문제해결을 위해서
"환경분석-> 계획수립-> 테스트 케이스 생성-> 테스트 및 문제해결-> 검증" 의 순서로 진행합니다.

누구나 빠른 문제해결을 원하지만 실제로는 "바로 해결하기"를 하는 경우가 많습니다.
다행스럽게도 운이 좋아서 빠른시간에 해결이 된다면 좋겠지만, 여러가지 포인트에서 문제발생의 여지가 있는 경우가 대부분 이므로,
빠른 문제해결을 위해서는 절차를 따르는 것이 좋습니다.

실제 많이 경험하시게 되는
웹페이지의 한글이 깨어지고 있는 상황을 가정하고, 문제를 추적해 보겠습니다.

1. 환경분석

장애가 일어난 시스템의 구조는 Apache, Proxy_ajp, Tomcat, MySQL로 구성되어 있습니다.

그런 경우 euc-kr 또는 UTF-8로 인해서 문제가 일어날 수 있는 WeakPoint 는 아래와 같은 곳입니다.



2. 계획수립
사소한 일이라면 그냥 머리속으로 계획을 세우면 되겠죠.
하지만 좀 시간이 걸리는 일이라면, WBS를 구성해서 제대로된 일정계획이 있는 것이 업무를 현명하게 하는 방법입니다.
이 문제는 그렇게 오래 걸리는 문제가 아닐꺼라고 판단하고, 즉시 수행하기로 했습니다.

3. 테스트케이스생성
해당 문제를 해결하기 위한 테스트에 필요한 케이스를 우선 구상합니다.
머리속으로 하셔도 되고, 메모하셔도 좋습니다. 전 그냥 머리속으로 했습니다 :-)

WEB
- 캐릭셋을 설정하지 않고 한글을 제대로 표현하는지 테스트합니다.
- 캐릭셋을 원하는 설정으로 변경하고 한글표현을 테스트합니다.

Connector
- get으로 한글을 전달해서 제대로 나오는지 확인합니다.

WAS

- 캐릭셋을 설정하지 않은 상태에서 한글이 제대로 나오는지 확인합니다.
- 캐릭셋을 변경해서 변환이 정상적으로 되는지 확인합니다.

DB
- 콘솔에서 직접 한글을 조회해서 확인합니다.
- collection을 확인하고 원하는 설정으로 변경해서 한글을 입력하고 조회해 봅니다.

4. 테스트 및 문제해결
생각한 테스트 케이스를 수행하면서, 문제를 해결하는 단계입니다.
기술수준이나 경험에 따라서 차이가 좀 있겠지만, 차근차근 한가지씩 해결해나가는 방법이 가장 빠른방법입니다.

WEB
이 시스템은 웹서버로 Apache를 사용하는 경우 입니다.
아파치의 경우 html문서의 상단에 아래와 같은 방식의 정의가 없다면 기본적으로 사용할 캐릭셋을 설정가능합니다.
<meta http-equiv="Content-Type" content="text/html; charset=EUC-KR">

httpd.conf 파일에서 AddDefaultcharset을 원하는 캐릭셋으로 변경한 후 한글의 출력상태를 확인합니다.

Connector
웹서버의 요청을 WAS로 넘겨주는 역할을 합니다.
이 부분에서 POST, GET으로 넘기는 변수를 WAS로 전달할 때 캐릭셋을 변경할 수 있기때문에 확인해야 합니다.
이 시스템의 경우 tomcat 의 server.xml 파일에서 URIEncoding을 설정해 주거나, useBodyEncodingForURI="true" 를 설정하여 캐릭셋을 설정할 수 있습니다.
useBodyEncodingForURI 설정은 이전페이지에 설정된 캐릭셋을 그대로 따른다는 설정이다.

JAVA
Tomcat이 구동될 때 별도의 설정이 없다면 JVM은 ISO-8859-1로 동작합니다.
따라서 한글의 사용을 위해서 tomcat 구동을 시키는 계정의 .bash_profile을 수정해서CATALINA_OPTIONS=-Dfile.encoding=euc-kr 을 추가해서 동작하도록 설정해야 합니다.

캐릭셋이 지정되어 있지 않은 경우의 기본 캐릭셋 설정은 web.xml파일에 아래처럼
기본적으로 사용할 캐릭셋을 지정할 수 있습니다.

<mime-mapping>
<extension>htm</extension>
<mime-type>text/html;charset=euc-kr</mime-type>
</mime-mapping>
<mime-mapping>
<extension>html</extension>
<mime-type>text/html;charset=euc-kr</mime-type>
</mime-mapping>

톰캣의 한글 파라미터 설정에 대한 다른 글 http://bit.ly/9DsGlW

JDK
String클래스의 getBytes() 메소드 사용하여 변경하는 경우는 아래처럼 사용합니다.
String(str.getBytes("8859_1"),"KSC5601");

페이지 상단에 캐릭셋을 지정하는 경우는 이런방식으로 사용합니다.
request.setCharacterEncoding("UTF-8");

JDBC
JDBC에서 유니코드 사용하기를 참고하세요 http://bit.ly/cEP9Qa

MySQL Server
my.cnf 파일에서 한글관련 설정을 변경해줍니다.
default-character-set=euckr
자세하세 설명한 글이 있어서 링크합니다. http://bit.ly/ac8jdT

DB, Table, Field
아래의 명령어를 이용해서 현재의 설정을 확인 후 변경해 줍니다.
show variables like "%character%";
show variables like "%collation%";

자세한 변경방법 http://bit.ly/awd7Jk


5. 검증
실 서버에 적용하고, 통합테스트를 수행해서 검증합니다.

증강현실이 어떻게 비지니스에 사용되는가?
증강현실이란 실제의 사물에 영상을 합성해서 보여주는 기술을 의미합니다.
백문이 불여일견 우선 동영상을 보세요.

해외 사례 - 독일 메타이오(Metaio)가 만든 의류쇼핑몰 허스트


국내 적용사례 - 영상처리 전문없체 유먼더스(대표 김주헌)가 만든 버추어피팅


증강현실을 이용한 레이싱

RACER DEMO 0.1 - video game mashup from sputnic on Vimeo.


앞으로 이렇게 되지는 않을까요? (만화지만 의미심장합니다)




새로운 개념을 주변에 설득하기 위해 노력할 때 명심해야 할 점.

Q: 높은자리에 있으면 전파가 쉽지 않나요?

A: 잘못된 생각입니다.

Q : 객관적 수치로 보여주거나 사례중심으로 보여주어야 전파가 쉬운가요?

A : 그것보다 더 중요한 것이 있습니다.


사람들은 설득을 하기 위해 객관성(수치자료나 사례 등)이 필요하다고 생각합니다.
하지만 이 객관의 개념 자체가 매우 주관적입니다.

결국 결정하는 것은 사람입니다. 그 사람 마음에 드냐 안드냐, 이겁니다.
안들면 어떤 이유를 들어서든 반대하게 됩니다. 도대체 누구의 "객관"이냐 이거죠.
가만히 보면 우리는 그동안 우리의 객관만 신경을 쓰는 실수를 저지른 겁니다.

품질(quality)에 대한 이런 정의가 있습니다.

Quality is value to some person (품질이란 누군가에게 가치가 되는 것이다).
-- Gerald Weinberg (와인버그, 번역 김창준)

똑같은 제품을 놓고도 어떤 사람은 품질이 좋다, 어떤 사람은 형편없다는 말을 할 수 있습니다.
어떤 사람에게는 기능이 다른 사람에게는 결함이 되기도 한다는 의미입니다.

"상대방에 대해 얼마나 이해를 하고 계신가요? 얼마나 대화를 해보셨나요?"

품질이든 설득이든 사람을 빼놓고 이야기 할 수가 없습니다.


설득에 대한 이야기

http://agile.egloos.com/5370989


더보기



관련링크

- 김창준씨의 KAI(Kirton Adaption-Innovation)관련 소개와 특징
http://www.ibm.com/developerworks/kr/library/dwclm/20091027/index.html

- 조직 & 혁신에 관한 읽을만한 뉴스레터
http://www.kmac.co.kr/newsletter/default.asp
  *  최고의 경력관리, 재능과 적성에 투자하라 (http://www.kmac.co.kr/newsletter/read.asp?topmenuKind=&board_kind=&Pk=1407&intpage=1&and_topmenu=)

- HDBI 및 KAI 소개
http://blog.naver.com/braincare/20012493034

HTML5에 대해 들어보셨습니까?
구글이 HTML5 지원을 공개적으로 천명하고,
애플과 어도비사의 HTML5 동영상 이슈로 새로운 웹 기술에 대한 궁금증을 더해 가고 있습니다.

아래 주소에서 HTML5 에 관련한 여러가지 동영상을 보실 수 있습니다.

http://webappscon.com/html5/video/

이미지 : html의 역사 - 발표자료 중


발표자료 다운로드 http://www.slideshare.net/Channy/html5-html5-open-conference/download

실전 HTML5 가이드
http://webstandards.or.kr/html5/

'개발도 하냐?' 카테고리의 다른 글

증강현실의 비지니스 기회  (0) 2010.08.09
사람에 대한 생각을 먼저해야 한다.  (0) 2010.08.04
HTML5  (0) 2010.08.03
요구사항 관리도구의 비교  (0) 2010.08.02
개인 주민등록번호 노출상태 확인  (0) 2010.08.02
QR코드  (0) 2010.07.26
상용제품들 비교


공개SW기반의 요구사항관리 도구들

http://www.softdevtools.com/modules/weblinks/viewcat.php?cid=93

위 주소에서 확인하시면 다양한 요구사항 관리도구를 검토해 보실수 있습니다.

저는 예전 setool에 있던 RM(e4net)이 있어서 설치 했지만, 오류인 상태라서 쓸만한 도구에 대한 검토중입니다.
시뮬레이션이 제공되는 정도라면 흡족하겠는데, 검토해보는데 시간이 좀 걸리네요.

요구사항이 관리되고, 다이어그램 몇가지가 나오고, 기능점수산정방식으로 계산되어 나오는
요구사항 관리도구를 원하는데.. 만들어야 할까요?


'개발도 하냐?' 카테고리의 다른 글

사람에 대한 생각을 먼저해야 한다.  (0) 2010.08.04
HTML5  (0) 2010.08.03
요구사항 관리도구의 비교  (0) 2010.08.02
개인 주민등록번호 노출상태 확인  (0) 2010.08.02
QR코드  (0) 2010.07.26
소스코드만으로 부족함이 느껴질때-RAD  (0) 2010.07.14
인터넷진흥원에서 개인정보보호를 위한 서비스를 제공합니다.

천천히 읽어보니 확인만 해주는것이지 탈퇴를 대행해주는 서비스는 아닙니다.
저는 확인해보니 탈퇴할곳이 많아서, 하루꼬박 걸렸네요.

http://clean.kisa.or.kr/


탈퇴를 진행하다보니 아예 탈퇴하기를 메뉴로 제공하지 않는 곳도 있습니다.
서비스를 운영자는 가입자의 입장에서 재가입하고 싶은 마음이 들도록 해야겠네요.~

그런데 우리나라에서는 왜 이렇게 주민등록번호를 많이 받는 걸까요?
반드시 받아야 하는 서비스라면 이해가 가지만, 별로 상관없는 서비스에는 좀 완화하는게 필요하겠네요.



'개발도 하냐?' 카테고리의 다른 글

HTML5  (0) 2010.08.03
요구사항 관리도구의 비교  (0) 2010.08.02
개인 주민등록번호 노출상태 확인  (0) 2010.08.02
QR코드  (0) 2010.07.26
소스코드만으로 부족함이 느껴질때-RAD  (0) 2010.07.14
Social Network, Social Media  (0) 2010.07.14

QR Code?

QR Code는 일본의 Denso Wave에 의해서 개발된 2차원 구조의 기호이며 대중적인 사용을 위해 특허권을 행사하지 않겠다고 선언하고 1994년에 배포 되었다. QR은 Quick Response의 약자이고 특징으로는 빠른 디코딩이 가능하고 기존 사용되어지는 바코드에 비해 대용량, 많은기록, 고밀도, 오류정정 기능 등이 있다.
일본에서는 책의 커버에 책에 대한 정보를 찾아 볼수 있도록 기록되기도 하고, 회전 초밥집의 접시에 붙여져 있거나 거리에서도 쉽게 찾아 볼수 있고 생활전반에 필요한 정보인 즉 명함, 전화번호, 문자, 홈페이지URL등 활용할수 있다.

내 명함 QR Code


스마트폰에서 스캐너 앱을 설치한 후 명함리더기로 활용가능.

아이폰 바코드 스캐너 '스캐니'


안드로이드용 QR코드 스캐너, 스캐니 1.0




사용 예


QR 코드 생성하기

'개발도 하냐?' 카테고리의 다른 글

요구사항 관리도구의 비교  (0) 2010.08.02
개인 주민등록번호 노출상태 확인  (0) 2010.08.02
QR코드  (0) 2010.07.26
소스코드만으로 부족함이 느껴질때-RAD  (0) 2010.07.14
Social Network, Social Media  (0) 2010.07.14
데이터에서 배우자  (0) 2010.07.14
좀 오래된 책이긴 하지만, 여전히 매우 유용한 스티브 맥코넬의 RAPID Development이란
책에 나오는 RAD 적용 사례입니다.
열심히 하는 코딩만으로는 부족함을 느낄 때 반드시 읽어봐야 하는 내용이죠.

예전에 한번 봤던 책인데 이번에 다시보게되는 기회가 있어서
적용사례 한페이지를 타이핑했습니다. 도움이 되시기 바랍니다.




제품2.0을 만드는 프로젝트의 기술수석 사라의 이야기

첫 회의에서 그녀는 팀원을 소개한 후 바로 본론으로 들어갔다.
"회사 프로젝트 전체의 사후 분석을 검토했습니다. 이제까지 다른 프로젝트에서 저지른 실수 목록이 1킬로미터는 족히 되더군요. 이 목록을 회의실에 붙여놓겠습니다. 우리가 이들 중 어떤 실수라도 저지르는 기미가 보이면 경고해줄것을 부탁합니다. 또한 여러분이 이미 알고 있거나 앞으로 부딪히게 될 가능성이 있는 실수를 추가해 주십시오. 이미 겪은 일을 이유없이 반복할 필요는 없다고 봅니다."

"저는 여러분 각자가 개발 기본에 충실하기 때문에 이 팀 구성원으로 뽑았습니다. 나중에 불필요한 수정따위에 시간을 낭비하지 않을 수 있도록 제대로 요구사항을 분석하고 설계하는 활동이 얼마나 중요한지 여러분은 잘 알 것입니다. 저는 여러분이 그저 열심히 일하기 보다는 현명하게 일했으면 합니다. 무작정 열심히 일하면 그만큼 많은 실수를 저지르게 됩니다. 우리에게는 그럴 시간이 없습니다."

"위험 관리 계획도 세웠습니다. 일정이 너무 꽉 짜여 있기 때문에 미리 막을 수 있는 위험에 발목을 잡힐 수는 없습니다. 이 목록에서 가장 큰 위험은 일정을 맞출 수 없을지도 모른다는 점입니다. 그래서 이번주는 일정을 재평가했으면 합니다. 만약 달성할 수 없다면, 좀더 현실적인 계획을 세우도록 합시다."

팀원 모두가 고개를 끄덕였다. '죽음의 행군'식 프로젝트를 해왔던 사람들은 사라의 이야기에 매우 동감했다.

그 주 후반, 사라는 상사 에디와 회의를 했다. "개발팀과 프로젝트 일정을 진지하게 검토한 결과, 현재 일정으로 현재 요구기능을 완료할 확률이 약 5% 정도라고 결론을 내렸습니다. 아무것도 변하지 않는다는 가정에서입니다. 물론, 항상 뭔가가 변하게 마련이지요."

"그건 안됩니다." 에디가 말했다. "정시 출시 가능성이 적어도 50/50은 되야 합니다. 게다가 출시 후 12개월 동안은 시장의 변화에 대응할 수 있어야 합니다. 어떻게 했으면 좋겠습니까?"

"아직 제품을 완전히 구체화하지 않은 상태라서, 융통성은 약간 있습니다." 사라는 대답했다. "그렇지만 현재 요구기능을 완성하려면, 10개월에서 30개월 정도 걸린다고 봅니다. 너무 범위가 큰 줄은 알지만 우리가 만드는 제품에 대해 더 알기 전에는 이것이 최선의 추측입니다. 제품을 12개월만에 출시해야 하지요? 그 점을 고려한다면 개발자를 더 추가해야 합니다. 그리고 8개월 째에 첫 출시를 한 후 두달마다 출시용 버전을 만드는, 점진적인 출시계획을 세워야 한다고 봅니다."

"괜찮군요" 에디가 말했다. "게다가 이번 프로젝트에서는 기능이 일정보다 더 중요하다고 생각됩니다. 회사와 좀 더 논의한 후에 다시 이야기합시다."

에디는 사라에게 돌아와, 회사가 필요한 기능 완료를 위해 일정을 14개월까지 늘일 용의가 있다고 전했다. 또한 안전을 위해, 점진적인 개발법을 그대로 사용하도록 지시했다. 사라는 안심하며, 그것이 좀더 현실적인 목표라고 생각한다고 대답했다.

첫 몇 주 동안에 팀은 구체적인 사용자 인터페이스 프로토타입을 작성했다. '실수 목록'에서 프로토타입에 들이는 지나친 노력을 경고하였으므로, 프로토타입 치장을 피하기 위해 기간확정 방법을 사용하기로 했다. 팀은 구현할 기능을 결정하기 위해 고객들을 면담하는 데 프로토타입을 이용하고 사용자 피드백에 따라 이를 여러 차례 수정했다.

사라는 계속 위험 목록을 관리했다. 그녀는 프로젝트에서 가장 큰 위험은 '엄청난 수정을 요구하며 일정을 늘이는 낮은 품질', '무리한 일정', '경쟁력을 위해 도중에 추가하는 기능', 이 세 가지로 결정했다. 사라는 점진적인 출시 계획으로 '품질 위험'에 대응한다고 보았다. 팀은 8개월째에 첫 버전을 품질관리부에 넘길 예정이고, 품질관리부는 이에 맞춰 테스트 스크립트를 개발할 것이다.

팀은 기능 우선순위 목록을 만들어 일정 위험을 다루었다. 14개월안에 무조건 많은 기능을 개발하는 방법도 있겠지만, 제품을 두 달마다 출시가능한 상태로 만듦으로써 어느 시점이든 출시할 수 있는 제품을 확보할 것이다. 팀은 또한 몇가지 기능에 대해 구현시간을 줄이는 방식으로 설계를 했다. 시간을 덜 들여 구현할 기능은 별로 매끄럽지는 않겠지만 쓸만한 것이며, 이런 결정으로 일정 위험을 상당히 줄일 수 있었다.

팀은 '경쟁력 향상용 기능 위험'을 두 가지 방법으로 대응했다. 그들은 5개월정도 시간을 들여, 프로토타입한 모든 기능과 3.0에 포함할 기능을 지원할 수 있는 기반구조를 설계하였다. 이 기반구조로 변화를 큰 어려움 없이 수용하기 위함이다. 또한 팀은 12개월 째 시간을 할당하여, 경쟁사의 제품을 분석하고, 프로토타입을 재검토하기로 했다. 그 후 마지막 두달 동안, 경쟁력향상을 위해 필요한 기능을 구현하기로 했다.

6개월 시점에서 설계를 완성함과 동시에, 팀은 8개월째에 품질관리부에 넘길 첫 출시용 버전을 위해 중간목표를 상세하게 명시하는 세밀한 계획을 세웠다. 첫 버전은 별로 많은 기능을 포함하지는 않았다. 그러나 품질이 우수했고, 그 후 개발에 좋은 바탕이 되었다. 8개월째에 다시 10개월 지점을 위해 중간목표를 상세하게 명시하는 세밀한 계획을 세웠다. 12개월 지점을 위해서도 같은 방법을 사용했다.

12개월째 팀은 계획대로 경쟁회사제품을 분석했다. 경쟁사 하나가 10개월 무렵에 좋은 제품을 출시했고, 그 제품에는 우수한 기능이 들어 있었다. 제품2.0이 경쟁력을 가지려면 꼭 추가해야 하는 기능이었다. 팀은 새 기능들을 우선순위 목록에 추가하고 우선순위를 재조정하여 마지막 두달을 위한 상세계획을 세웠다.

그 즈음에 연구원들 중 호세가 좀더 나은 대화창 구성을 생각해내고, 팀회의에서 안건으로 제시했다. 선임 연구원 조지가 대답했다. "아이디어는 좋아. 바꾸는 편이 낫다고 생각하지만, 지금은 안되네. 호세 자네는 하루정도면 고칠수 있겠지만, 문서화 일정에 일주일 혹은 그이상 영향을 미치네. 버전 3.0 목록에 넣으면 어떨까?"

"문서화 일정에 미치는 영향을 미처 생각하지 못했습니다." 조는 말했다. "좋은 지적이군요. '나중에 할일' 목록에 추가하도록 요청하겠습니다.

14개월째 팀은 계획대로 최종 소프트웨어를 출시했다. 제품2.0의 품질은 8개월째부터 테스트를 해왔으므로 우수했다. 문서부는 소프트웨어가 완성되기를 기다리는 대신 상세한 인터페이스 프로토타입을 바탕으로 일할 수 있었기 때문에, 사용자 매뉴얼 역시 최종 소프트웨어와 같은 시기에 끝낼 수 있었다. 개발팀은 우선순위가 낮은 기능까지 구현할 시간은 없었지만 중요한 기능은 모두 구현했다. 제품2.0은 성공적이었다.

'개발도 하냐?' 카테고리의 다른 글

개인 주민등록번호 노출상태 확인  (0) 2010.08.02
QR코드  (0) 2010.07.26
소스코드만으로 부족함이 느껴질때-RAD  (0) 2010.07.14
Social Network, Social Media  (0) 2010.07.14
데이터에서 배우자  (0) 2010.07.14
RAD(Rapid Application Development)  (0) 2010.07.08
기업입장에서 바라보는 소셜미디어의 활용에 대한 자료.

소셜미디어 활용하기(LG경제연구소)



주요 내용은 아래와 같다.

첫째, 기업의 특성에 맞게 소셜미디어를 활용하면 보다 많은 기회를 얻을 수 있다.

이미 많은 유수의 글로벌 회사들은 소셜미디어의 특성을 간파하여 이를 다양한 기업 활동,
즉 인재를 선발하고, 기업 생산성을 높이고, 기업의 혁신과 협업을 유도하며,
기업에대한 평판을 높이는 데 효과적으로 활용하고 있다
를 제공한다(델은 트위터를 통해 수백만 달러어치의 제품을 판매했을 뿐만 아니라 트위터 가입자
를 델 홈페이지로 유도하여 트위터 전용 상품을 판매하고 있다)

둘째, 기업이 대화를 주도할 수 있는 에코 시스템 구축을 통해서 전사적 발언이 가능하다

현재 국내 기업들은 트위터 계정을 만들고 홍보팀 내 담당자를 지정하여 소셜미디어를 활용하고 있다.
앞으로는 소셜미디어를 홍보의 일환이 아닌 기업 경영의 전체적 흐름에서 바라보아야 하며,
기업 커뮤니케이션 전체를 총괄하여 하나의 목소리를 낼 수 있도록 하는것이 필요하다.


셋째, 기업의 구성원간 쌍방향 의사소통의 도구로 활용하면 문제의 빠른해결이 가능하다.

소셜미디어는 사용자의 상호 작용과 관계에 의해 컨텐츠가 생산되고 확산되는 메커니즘을 가지고 있다.
주변의 네트워크를 통해 부여된 신뢰성을 기반으로 한 정보가 급속도로 퍼져나가는 특징을 지니고 있다.
홈페이지를 거쳐 블로그, 페이스북, 트위터로 이어지는 소셜미디어의 큰 흐름에 정치권 및 많은 기업들이 주목하는 것도 이 때문이다.
이는 과거의 통제 패러다임을 근간으로한 기업 내 관리는 더 이상 통용되기 힘든 시대가 도래했음을 의미한다.
대기업이든 중소기업이든 기업은 앞으로 더 이상 내부 임직원의 대내외 활동을 일일이 통제할 수 없다는 점을 인식해야 한다.

넷째, 기업경영 투명성 높이기

소셜미디어는 모든 것을 투명하게 보여준다.
과거에는 기업이 정보의 비대칭성을 이용, 기업에 유리한 일방적, 선별적 정보만을 소비자에게 전달함으로써
자사 제품을 홍보하는 것이 가능했다. 그러나 지금은 투명성이 경영의 기본으로 여겨지는 시대다




'개발도 하냐?' 카테고리의 다른 글

QR코드  (0) 2010.07.26
소스코드만으로 부족함이 느껴질때-RAD  (0) 2010.07.14
Social Network, Social Media  (0) 2010.07.14
데이터에서 배우자  (0) 2010.07.14
RAD(Rapid Application Development)  (0) 2010.07.08
디자이너에게 배우다.  (1) 2010.07.07
SKT에서 실시했던 안드로이드 공모전의 결과분석 자료의 내용입니다.

 - 안드로이드 공모전 수상작 28선 간단한 소개자료 바로가기

생활형 유틸리티(56%) > 엔터테인먼트(30%) > 게임(5%)
• 서비스연동형 37% | 위치정보이용 21% | 카메라이용 16%
• 용량은 평균 1.17MB (17KB ~ 15MB)

핵심 keyword: 지도 SMS 소셜 센서
Application mashup도 상당한 흐름 형성
트위터를 service infra로 활용하는 경우도 다수




수상작 (더많은 내용을 보시려면 링크를 이용해서 다운로드 받으세요)



심사가 어려웠던 내용




'개발도 하냐?' 카테고리의 다른 글

소스코드만으로 부족함이 느껴질때-RAD  (0) 2010.07.14
Social Network, Social Media  (0) 2010.07.14
데이터에서 배우자  (0) 2010.07.14
RAD(Rapid Application Development)  (0) 2010.07.08
디자이너에게 배우다.  (1) 2010.07.07
PHP 코딩 규약 - PEAR  (0) 2010.06.25

+ Recent posts