Twitter의 특징은 (1) 리얼타임에 가까운 커뮤니케이션에도 어카이브(archive)적으로도 사용할 수 있는 심플함과 유연함 (2) 클라이언트의 다양성이나 외부 서비스와의 제휴가 쉬움.

 

심플, 다양화로 유저를 늘린다

우선 블로그나 SNS(소셜 네트워킹 서비스)등에 비교해 투고의 허들이 낮다. 「타이틀 불요」로 「1 140문자 제한」 때문에 생각한 것을 메모와 같이 자꾸자꾸 써 갈 수 있다. IPv6은 필요한가?」라는 기술론으로부터 「오피스 뒤의 도시락은 맛있다」등 정신 없는 화제까지 지금까지 텍스트 데이터로서 정착하기 어려웠던 군소리를 유저로부터 꺼내는 것에 성공하고 있다.

 

각 유저가 투고한 트윗은 유저끼리의 관계에 의해서 여러 가지 가치를 가지게 된다. Twitter에서는 유저끼리가 「팔로워」라고 부르는 구독관계를 묶는 것으로 팔로워한 유저의 트윗이 자신의 홈 화면에 시계열로 줄 선다. 시계열로 줄선 트윗의 모임을 「타임 라인」이라고 부른다.

 

유연한 사용법을 지지하는 것이 API를 개방해 외부 서비스나 개발자를 불러 들이는 시책이다. Web 브라우저 뿐만이 아니고 전용의 클라이언트 소프트나, iPhone 등의 스마트 폰, 휴대 전화로부터 투고할 수 있다. 행선지 등에서도 용이하게 중얼거릴 수 있기 때문에 투고수가 증가해 그 결과 한층 더 유저가 증가한다고 하는 호순환이 태어나고 있다.

 

여기에서는 전술의 특징에 따라서 Twitter해부해 나간다. 이하에서는 「심플한 서비스를 신속히 전개하기 위한 구조」를 다음 번에는 「급속한 유저수의 증가에 견딜 수 있는 시스템」과 「다양한 클라이언트로부터의 투고의 실현」을 취급한다.

 

 

 

클라우드 활용으로 확장성 있게

 

Twitter를 구성하는 서비스랑 소프트웨어를 보면 그 인프라 부분의 대부분이 외부 서비스에 의존하고 있는 것을 알 수 있다. 구체적으로 아이콘 그림이나 JavaScript등 각종 파일을 다루기 위해 아마존닷컴의 자회사인 아마존 웨이브 서비시즈의 클라우드 서비스 ‘Amazon S3’를 활용하고 있다.

 

 

유료 서비스

Amazon S3

온라인 스토리지 서비스

 

Amazon CloudFront

콘텐츠 배신 서비스

무료 서비스

Google Analystics

액세스 분석 서비스

오픈 소스

Apache

HTTP 서버

 

Cache-money

Ruby on Rails용 캐시 서버 자사 개발

 

Kestrel

메시지 캐싱 서버 자사 개발

 

libnencached

Memcached 클라이언트 자사 개발

 

Memcached

분산 메모리 캐시 서버

 

Mongrel

HTTP 서버

 

MySQL

RDB

 

Nagios

운용감시 소프트

 

Ruby on Rails

Web 애플리케이션 프레임워크

 

Valgrind

시스템 분석 툴(디버거)

 

Amazon S3 HTTP/HTTPS로 파일을 다루는 온라인 스토리지 서비스.

용량은 무제한으로 저장한 파일의 데이터 량과 입출력 회수, 네트워크 전송량에 따라서 과금이 발생하는 종량제 요금 서비스이다.

Amazon S3를 사용하는 것으로 매일 증가하는 Twitter 내의 아이콘이랑 배경 그림등을 저장하는 스토리지의 초기 투자를 낮추고 쾌속한 서비스 전개가 가능하게 되었다. 유저 수가 급증하여도 스토리지 기기의 증설에 쫒기는 일은 없다.

 

 

 

아마존의 CDN 서비스로 국내 배신

 

서비스의 쾌속적인 전개만이 아닌 유저에게 사용하기 쉬운 환경을 실현하기 위해서도 외부의 클라우드 서비스를 활용하고 있다. 실은 국내의 유저가 Twitter을 이용할 때 그 트래픽의 대부분은 일본 국내에서 처리하고 있다. 아이콘 그림이나 JavaScript를 둔 장소에 Amazon S3의 옵션 메뉴에 있는 CDN 서비스 ‘Amazon CloudFront’를 시용하여 네트웍 딜레이를 작게한다.

 

CloudFront를 병용하는 것은 데이터의 복사를 보내는 곳의 가까운 곳 이를 테면 유저에게 가까운 장소에 두는 것이 목적이다. 미국의 스토리지와 일본 사이는 약 8000km 정도 떨어져 있다. 빛에 가까운 속도로 전달하는 전기신호라도 일본과 미국을 왕복하는 시간(RTT:round trip time) 180밀리세컨드가 걸린다.

 

CloudFront 2009 12월 시점에서 미국내의 8 지여그 유럽의 4 지역, 아시아의 2 지역(도쿄와 홍콩)에 배신 서버를 두고 있다. Amazon S3 내의 파일에 액세스 하면 유저는 가장 가까운 배신 서버에 안내된다.

 

실제 일본에서 Twitter를 사용할 때 통신 내용을 보면 ‘twimg.com’이라는 도메인에 액세스하는 것을 알 수 있다. RTT 16밀리세컨드 전후.

 

 

 

출처 : http://itpro.nikkeibp.co.jp/article/COLUMN/20100602/348733/?ST=network&P=1

 

 

 

저작자 표시
신고
by 흥배 2010.07.27 09:30
일본의 GameBusiness.jp에서 아이들과 게임에 관한 설문 조사를 한 결과 입니다.



출처 : http://www.gamebusiness.jp/article.php?id=1884

저작자 표시
신고
by 흥배 2010.07.23 09:30
일본의 GameBusiness.jp에서 아이들과 게임에 관한 설문 조사를 한 결과 입니다.



출처 : http://www.gamebusiness.jp/article.php?id=1884

저작자 표시
신고
by 흥배 2010.07.23 09:30

Danny Kalev

장래에 대해서는 어떻게 생각합니까? 지금부터 어떻게 됩니까? Technical Report 같은 느낌으로Concept를 나중에 추가하는 것입니까? 혹은 완전 초보나 아직도 깨달음을 얻지 않은 우둔한 코더라도 사용할 수 있는 완전히 새로운 규격을 넣는 날이 오는 것입니까? concept의 폐지는 현행 드래프트에 한층 더 큰 영향을 주는 것입니까?

 

Bjarne stroustrup

어휴, 편견이 심한 유도 심문 같은 질문이네요

 

가장 먼저 C++0x는 이미 합의된 개량을 모두 도입하여 제정되었어요. 예를 들어 concurrency의 지원, 표준 라이브러리의 개량과 확장, 통일적인 초기화, lambda, move semantics, 범용적인 정수 표현 등등. 제가 썼던 C++0x FAQ를 읽어보세요. 이미 이 단계에서는 대규모 변경은 들어가지 않아요. C++0x에는 중요한 개량이 많이 있어요. 몇 개인가는 이미 GCCMicrosoft 등이 구현하고 있어요. 새로운 언어와 같다고 느낄 것이에요.

 

2번째로 C++은 모든 유행을 쫓는 일은 하지 않아요. 실용을 위해 천천히 호환성을 생각하면서 진화해 나가요. 최첨단 기능이 가득한 언어라든지 극단적으로 작은 언어라든지 독자 기능이 가득한 언어라고 하는 오징어 한 언어를 갖고 싶다면 그 외에 얼마든지 있을 것이요. 다만 만약 이 앞 몇 십년 이라도 사용하는 프로그램을 위해 충분히 유연하고 보다 성능이 좋은 그 외 예를 볼 수 없을 정도 범용적이고 어떤 하드웨어에도 움직이는 언어를 갖고 싶으면 C++로 하세요.

 

3번째로 많은 사람이 어떠한 방법으로 C++에 있어서의 Concept의 좋은 점과 올바른 이용 방법을 찾아낼 것이에요. 「나중에 추가」하는 것은 아무도 생각하고 있지 않아요. C++의 표준화는 그처럼 되지 않아요. 프랑크푸르트 이전의 Concept 규격에 "simplifying the use of concepts" 제안으로 개량을 더하면 개인적으로는 만족이 가는 것이 수개월에 완성될 것이에요. 하지만 그런 일은 없을거에요. concept을 기본으로부터 다시 생각히여 지금까지 얻을 수 있던 경험을 바탕으로 한다고 해도 거의 스크래치로부터 규격을 고쳐 써고 실험할 것이에요. 5년 단위의 시간이 걸릴 것이겠죠. 무엇보다 concept은 다른 아이디어에 이길 정도의 이점을 나타내지 않으면 되지 않아요. 만약 리플렉션이 우수하다면 대신에 그쪽에 주력 할 것이에요.

conceptTR(Technical Report)에 향하고 있다고는 생각되지 않아요. 형태 시스템에 깊게 관련되고 있기 때문에 TR라고 하는 것은 그것 없이도 해 나갈 수 있는 만큼 분리할 수 있는 것에 대해서 실시해요. 형태 시스템은 완전하게 완수할지 아무것도 하지 않을 지의 양자택일이에요.

 

 

 

Danny Kalev

그러면 C++에 관해서는 낙관적인 견해를 하고 있군요.

 

Bjarne stroustrup

저는 옛날도 지금도 주의 깊고 낙관적으로 생각하고 있어요. 저는 「 나의 언어, , 설계 사상을 가지고 있으면 너희들의 별볼일 없는 문제 전부 해결해 줄 수 있어! 내일이라도 세계를 정복해 주지! 후하하하하!」등의 낙관적인 견해는 있지 않아요. 저시는 C++이 「단지 단지」 몇 백 만명의 프로그래머를 지원할 수 있고 많은 환경에 소프트웨어의 개발 환경을 제공하여 고도의 어플리케이션 개발에 사용된다고 하는 것만으로 충분히 만족해요. 「소프트웨어의 환경」이라고 하는 것은 임베디드계이거나 시스템 개발이거나 자원의 제약이 어려운 환경이거나 C++에 최적인 분야의 것이에요. C++0xC++98보다 보다 좋은 툴이 될 것이에요.

 

지금으로서는 위원회는 C++0x를 아담하게 포장하고 출하하지 않으면 않되요. x16진수가 되지만. 그리고 구현이 다 모일 것이에요. 몇 개의 기능이나 라이브러리는 이미 나돌고 있어요. 거기서 프로그래머는 위원회의 다대한 작업의 혜택을 얻을 수 있다는 것이에요.

 


< 끝 >


Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474

Bjarne Stroustrup Concept와 미래를 말하다 – 4 http://jacking.tistory.com/559

Bjarne Stroustrup Concept와 미래를 말하다 – 5  http://jacking.tistory.com/652

Bjarne Stroustrup Concept와 미래를 말하다 – 6  http://jacking.tistory.com/678

Bjarne Stroustrup Concept와 미래를 말하다 – 7  http://jacking.tistory.com/679

Bjarne Stroustrup Concept와 미래를 말하다 – 8  http://jacking.tistory.com/686

Bjarne Stroustrup Concept와 미래를 말하다 – 9  http://jacking.tistory.com/695

 

저작자 표시
신고
by 흥배 2010.07.21 08:30

Danny Kalev

흥미롭네요. C++98template의 컴파일 방법으로서 현실적으로 사용되고 있는 inclusion 모델과 exportDouglas Gregor가 텍사스와 인디애나라고 말하는 같고, 두 개의 사상을 하나의 제안에 정리하려고 한 결과입니까? 아무래도 그런 식으로 동일 시 하는 것은 잘 되지 않을 것 같네요.

 

 

Bjarne stroustrup

그래요. export의 실패는 templateinclusion 모델) separate compilation 모델을 하나로 정리하려고 한 것입니다. 다만 당신이나 모두에게 알려 주고 싶은 것은 당시 어느 쪽의 방법도 실제로 사용되고 있었던 것입니다. 표준의 방법이 아무래도 필요했고 어느 쪽의 모델도 강하게 지지를 받고 있었습니다. 그러한 이유로 절충안은 만들기 힘들었습니다. 이쪽을 세우면 저쪽이 서지 않으니까요.


반성해 보면 양쪽 모두의 모델을 절대로 지원할 필요가 없었기 때문에 벤더는 inclusion 모델만을 구현했을 것입니다. EDGexport를 구현하고 있습니다. 하지만 모든 주요한 벤더가 다 할 때까지 는 아무리 귀찮아도 사용하고 싶어하지 않는 것 같습니다. 당시의 저는 그런 것은 고려하고 있지 않았으며 위원회가 실패했던 것도 명확한 사용 구분을 생각하지 않았던 것이라고 생각합니다. 위원회를 꾸짖기 전에 조금 더 생각해 주세요. 「지금 현재 문제가 있다」라는 거소가 「장래 문제가 될지 모른다」 어느 쪽을 선택하는가 라는 것은 개인으로서는 매우 어려운 일이에요. 머리가 좋은 사람끼리 생각해도 어렵습니다.

 

concept 제안의 근본적인 차이를 분별하는 것은 매우 어려운 일입니다. 이 문제를 깨닫고 있지 않는 사람마저 있어요. 어려운 것은 「도대체 무엇이 근본적인 차이인가?」라고 하는 것입니다. 당연 논의의 상당수는 concept map이었습니다. 이미 나타난 것처럼 concept mapmapping을 위해서 필요한 기능입니다. 그 자체가 훌륭하다고 생각하는 사람도 있었습니다. 비록 비어서 무슨 형이나 조작도 정의하지 않는다고 하더라도 말이죠. 프랑크푸르트 이전의 concept의 규격 설계에서는 빈 concept map을 요구하는 concept과(explicit concept, mapping이 필요하지 않은 한 concept map을 필요로 하지 않는 conceptautomatic concept)이 있었습니다. "simplifying the use of concepts" 페이퍼로의 논점은 concept map은 애매성의 해결에 적절하지 않다는 것입니다. 이것이 당신의 질문에 대한 답입니다. concept map의 올바른 사용법에 관한 논의의 결론은 표준화 위원회에 의한 언어 사양에 반영 되는 것이 당연하고 concept와의 순조로운 해결의 방법이 제공되어야 한다는 것입니다. 다른 안은 다른 사상의 코드를 동일시로 하는 것으로 쓰기의 좋은 것은 아니었습니다. 거기서 올바른 사용법이라고 하는 것에 관련해서 격렬한 논의가 있었습니다.

 

 

 

Danny Kalev

C++유저는 적당히 하라고 생각하고 있는 것은 아닐까요? 논의가 좋은 예인 것 같습니다. concept만이 아니었죠. 가베지컬렉션이든가 리플렉션이라든지 GUI라고 하는 매우 갖고 싶은 기능이 C++에는 절대 들어갈 것 같지 않지요. 거기에 비하면 실험적으로 난해한 기능만 논의되고 있고. 이 코멘트에 있듯이 이제 C++라는 것은 끝난 것일까요? 언어 자체가 너무 복잡하여 더 이상 온전하게 개량 할 수 없게 되고 있는 것은 아닐까요?

 

 

Bjarne stroustrup

그 「매우 갖고 싶은 기능」이라는 것들이 이론이 많은 것이 문제예요. 단지 고함치듯이 주장만 하고 온전하게 논의를 하지 못했어요. 저는 개인적으로 GC를 좋아하고 C++0x에는 GC ABI도 들어갑니다. 단지 유감스럽지만 표준 GUI 따위는 무리입니다. 왜냐하면 세상에는 독자 구현이 너무 많기 때문입니다. 많은 업계가 자신의 GUI로 둘러싸고 싶어합니다. 「실험적으로 난해」라고 하는 것은 대체로 「내가 좋아하는 다른 언어에는 없어서 나에게 있어서는 이해 불가능한 기능」을 의미하는 것은 아닐까요? 이전에는 클래스 계층과 가상 함수가 그러한 기능이었습니다.

 

C++이 끝나는 것 일은 없습니다. 그러 말은 C++의 흉내를 내고 있는 무리들이 하는 말입니다.

C++의 표준화 방법은 확실히 늦고 어렵습니다. 단지 이미 말한 것처럼 가벼운 느낌의 실험적인 방법보다는 좋아요. 다른 방법이라고 하면 상업 언어의 진화는 빠릅니다. 왜냐하면 돈도 있고 다수의 환경을 고려 하지 않아도 되고 C++ 정도의 하위 호환성을 신경 쓸 필요가 없어니까요. Visual Basic을 기억하겠죠? C++VB만큼 빨리 진화하지 않는다고 자주 말해지고 있습니다. 하지만 C++은 기존의 코드를 가능한 한 부수지 않고 진화해 왔던 것입니다. 저는 아직도 숭고한 벨 연구소 같은 연구실이 새로운 아이디어를 실험하려면 최적의 장소라고 생각합니다.

많은 현장은 아직껏 C++98 조차 따라잡고 있지 않아요. 이것은 다른 언어에 말할 수 있는 것이지만.




Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474

Bjarne Stroustrup Concept와 미래를 말하다 – 4 http://jacking.tistory.com/559

Bjarne Stroustrup Concept와 미래를 말하다 – 5  http://jacking.tistory.com/652

Bjarne Stroustrup Concept와 미래를 말하다 – 6  http://jacking.tistory.com/678

Bjarne Stroustrup Concept와 미래를 말하다 – 7  http://jacking.tistory.com/679

Bjarne Stroustrup Concept와 미래를 말하다 – 8  http://jacking.tistory.com/686


저작자 표시
신고
by 흥배 2010.07.19 09:00

한국이 아닌 천조국(쌀나라)의 이야기입니다만 흥미로운 글입니다.

 

 

미시간주 칼빈 대학 컴퓨터 사이언스 교수인 Joel Adams씨는 컴퓨팅 분야의 직업 시장이라고 하는 보고서를 발표했다. 이 보고서는 컴퓨터 분야의 직업을 선택한 사람은 미래가 밝다는 것을 나타내고 있다. 이 보고서에는 3개의 큰 "놀라움"이 기록되어 있다.

 

1. 노동 통계국(USBLS)의 견적에서는 컴퓨팅 분야에서의 새로운 일은 그 외의 모든 엔지니어링의 분야의 새로운 일의 4배 이상이다.

2. 연간 새로운 직장은 컴퓨터 사이언스 학사의 수의 2배로 심각한 부족 상태가 되어 있다.

3. 컴퓨터 분야란 STEM (과학[Science], 기술[Technology], 엔지니어링[Engineering], 수학[Math])4개의 분야이지만 이 분야에서 학사의 수요가 공급을 넘고 있다.

 

이 보고서에는 졸업 예정 학사의 공급량이 수요를 계속 밑돌고 있으므로 컴퓨팅 분야의 전문직의 급료는 상승하고 있다 라고 지적하고 있다.

 

 

USBLS의 예측에서는 앞으로의 몇 년간 컴퓨팅 분야는 가장 급성장하고 있는 전문직이다. 3/4 가까이의 새로운 과학이나 엔지니어링의 일이 컴퓨팅 분야에 관계하고 있다. 이 중 27%가 소프트웨어 엔지니어링에 관련하고 21%는 컴퓨터의 네트워크와 관리에 관련하며 10%가 시스템 분석에 관련하고 있다.

 

학사에 대한 명확한 수요에 관계없이 컴퓨터 사이언스 학위를 선택하는 학생의 수는 감소하고 있다. 1998년에는 약 60,000명이던 학부생은 2007년에는 약 30,000명까지 침체되어 있다. 2년간으로는 입학자 수는 조금 상승하고 있다. 학생은 통상, 전공을 결정할 때 돈이 벌 수 있는 직업으로 이끌어 주는 전공을 하려고 하므로 매우 예민하다. 그러나 컴퓨팅 분야에서는 이 법칙은 들어맞지 않는다. 이것은 대부분의 경우 유포하고 있는 신화가 원인이다. 예를 들어,

 

* "모든 좋은 일은 인도에 가 버리고 있다". 실제는 상품화한 일만이 오프쇼어(offshore)화 되고 있다(몇 개의 통계에 의하면 매년 많은 일이 미국으로부터 유출되는 것과 동시에 많은 일이 미국에 돌아오고 있다).

 

* "남자의 일이다". 컴퓨터 사이언스의 클래스에는 거의 남성 밖에 없는 것은 사실이다. 그러나 실제의 노동 인구는 확실히 비율은 불균형이지만 성차에서는 그만큼 비뚤어지지 않았다. 예를 들면, 성차가 강조되지 않는 일과 같은 다른 일자리를 가진 사람이 대부분 컴퓨팅의 전문직에 참가하고 있기 때문이다.

 

* "컴퓨팅이라는 것은 프로그래밍이고, 프로그래밍은 파티션 안에서 스크린을 하루 종일 응시하고 있는 작업이다". 프로그래밍은 중요하지만 문제 해결책(프로그래밍의 발생원인)을 실현하기 위한 구현에 소비하는 시간보다 훨씬 더 많은 시간을 복잡한 문제를 이해하여 해결책을 만들어내기 위해서 타인과 작업하는 것으로 소비한다.

 

* "대단한 일이다". 수학, 이론, 하드웨어, 컴파일러, 프로그래밍 등의 연구 대학의 품질 보증이 되는 컴퓨터 사이언스의 프로그램은 의심 없이 보람 있는 커리큘럼이다. 그러나 더 많은 프로그램이 그 외의 중요한 커리큘럼을 구성하고 있다. 이러한 커리큘럼은 "소프트웨어 엔지니어링에 관련한 27%, 컴퓨터의 네트워크와 관리에 관련한 21%, 시스템 분석에 관련하고 있는 10%", 즉 컴퓨팅에 관련하는 일의 거의 60%의 일에 있어서 보다 적절한 지식이나 기술에 중점을 두고 있다. 이러한 커리큘럼은 "간단"할 필요는 없지만 꼭 '난해'한 것은 아니다. 배운 것과 그 중요함이나 타당성 그것을 적용하는 것 등을 묶는 것은 훨씬 간단하기 때문이다.

 

 

 

Peter Demming씨는 컨퍼런스를 개최하고 이 다른 신화에 주목을 모아서 컴퓨팅 교육의 매력을 학생에게 전하는 조직(Rebooting Computing)을 설립했다.

 

 

대부분의 신화와 같이 대학에서의 컴퓨터 사이언스의 교육이 훌륭한 직업을 이끌어 주는 것은 아니라고 하는 생각에는 진실이 포함되어 있다. 학술계가 학사에게 있어서 중요하다고 생각하고 있는 것으로 고용자가 학사에게 바라는 것이나 기대하는 것의 사이에는 분명한 단절이 있기 때문이다. Accenture 회사와 같이 거대한 컨설팅 회사는 "부트 캠프"를 개최하여 학사를 선발하고, 학사 이후의 교육과 트레이닝(회사 내의 트레이닝이나 OJT)를 도입하는 것으로 학사를 "돈을 벌 수 있다"가 되도록 하고 있다. 같은 직접 고용을 실시하고 있는 조직이나 기업에서는 전형적으로 학사가 한 사람 분의 전력이 되기까지는 1년간의 OJT"재교육"이 필요하다고 하는 소리가 높아지고 있다.

 

이 예측과 계산기 과학의 프로그램에 대한 학생의 불만과 그 교육을 받아 온 학사에 대한 고용자의 불만을 아울러 생각하면 검증과 해결이 필요한 하등의 치명적인 문제가 있는 것을 알 수 있다.

 

 

출처 : http://www.infoq.com/jp/news/2010/07/career-labor-statistics

 

저작자 표시
신고
by 흥배 2010.07.07 01:18
지난주 회사의 팀 스터디에서 발표한 것입니다.




초당 120만 트윗을 처리하는 twitter 시스템
View more presentations from jacking.




저작자 표시
신고
by 흥배 2010.06.28 10:49

Danny Kalev

「위원회에 의한 설계」라고 하는 접근은 실패의 원인이군요. concept이 비판 받는 것도 그 때문인 것 같군요. 예를 들면 export입니다.(나중에 알았지만 John SpicerBerlin 회의에서 비슷한 것을 말한다. 회의록은 여기. 무엇으로 위원회가 표준화 하는 것을 기존의 유효성이 보증되고 있는 것으로 한정하지 않을까요? 실제 그렇게 해서 STL이 만들어졌었죠. 그러면 C++0x도 좀 더 빨리 규격을 제정 할 수 있었지 않았을까요?

 

 

Bjarne stroustrup

1996년 시점에서 STL을 「기존의 유효성이 보증되고 있는」 물건이라고 생각하는 사람은 많이 있었다고는 생각되지 않습니다. 한층 더 라이브러리의 제안과 언어 기능의 제안은 많이 다른 것이에요. 라이브러리의 제안을 예측하는 것은 비교적 간단합니다.

프랑크푸르트 회의에서 제시가 지적한 것은

l  어느 사람은 「상용 구현이 없는 것을 표준화 하지 말아야 한다」라고 주장하고 있습니다.

l  주요한 벤더는 표준 규격 없이 구현을 하지 않습니다(상용적으로 이점이 있는 독자 기능이 아닌 한).

 

이 문제를 피하는 방법으로서는 실증을 위한 실험적인 구현을 제공하는 것입니다. 단지 이것은 논의를「충분히 완전한 구현 이라는 것은 어느 정도인가?」와 「실험적 구현의 표준 규격에 있어서의 기준도는 어느 정도 정확한가?」라고 하는 것으로 바뀔 뿐입니다.

 

Concept에서는 실험적인 구현인 ConceptGCC와 실제로 움직이는 STL이 있었습니다. 어느 사람에게 있어서는 이것으로는 충분하지 않았습니다. 단지 제가 생각컨대 많은 사람이 구현 문제에 너무 신경 쓰고 있어서 설계의 문제에는 무관심했습니다. 설계와 구현만으로는 불충분합니다. 기능을 사용한 라이브러리도 필요합니다. 그 라이브러리를 사용한 실제의 프로젝트도 필요합니다. 뭐 그렇다면 완벽하겠지만 그렇게 몇 년이나 실험만 하고 있을 틈은 없습니다. 누가 그런 실험적인 구현 후에 프로젝트나 제품을 만들까요? 만일 누군가가 했다고 해도 어떻게 그렇게 빠른 단계의 구현상의 경험을 바탕으로 미묘하게 다른 표준 규격을 제정 할 수 있다고 말할까요? 얻을 수 있는 것은 비호환 독자 기능이 증가해 가는 것 정도의 물건입니다. C++98C++0x의 사이가 긴 공백 기간이 Apple이나 Microsoft가 독자「기술」을 내고 있는 이유입니다. 단지 아무것도 그들에게 한정한 이야기는 아닙니다. 기업이라고 하는 것은 업계의 쉐어와 이익을 추구하는 것입니다. 언어 설계의 범용성을 위해 있는 것은 아닙이다.

따라서 일반적으로 새로운 아이디어를 평가하는 것은 어렵고 넓게 사용되고 있는 언어에 대하여 하는 것은 한층 더 곤란합니다. 불가능한 것이라고는 생각하지 않지만 저는 대부분은 실험적인 구현으로 충분하다고 생각합니다. 비록 완전하지 않았다고 하더라도 기능을 100% 구현하고 있지 않을지도 모르고, 다른 기능과의 균형이 충분하지 않을지도 모르고, 성능이 최적화되어 있지 않을지도 모르고, 디버그 기능이 빠져 있거나, 에러 메세지가 완전하지 않을지도 모르는 등등. 현실에서는 어느 정도의 실험이 충분할지 어떨지를 판단하지 않으면 안됩니다. 그러나 이것은 어느 기능에 필요한 것이 모두 받아 들여진다는 것은 아닙니다. 거기에 더해 필요한 것은 규격의 검증, 단순성, 완전성, 범용성, 확장성, usability, 사람에게 가르칠 수 있을지?

 

많은 설계안을 검증하지 않으면 안됩니다. 대부분의 경우 그저 몇 안 되는 규격 설계의 차이가 일반 프로그래머에게 있어서의 편리한 사용을 아득하게 바꿉니다. 구현 중시로 놓치는 것이 많은 것은 여기입니다. 저시는 「전형적인 이용 예」와 「중요한 이용 예」를 모아서 많은 설계를 시험하고 있습니다. WG21 사이트에 있는 initializer listinitialization에 관한 많은 페이퍼가 이 어프로치를 실천하고 있습니다. 한층 더 저는 튜토리얼 쓰기, 학생에게 복수의 설계안을 시험하게 하는 것을 하고 있습니다. 물론 다른 언어 기능과의 균형이나 장래의 확장을 검증하는 것도 필요합니다.

 

더 재 빠르게 라고 단순하게 「위원회에 의한 설계」이외 방법으로 게다가 금전적 원조가 필요 없고, 기업의 영향도 받지 않는 듯한 규격 설계 방법이 있다고 생각하는 것은 실수입니다. WG21에서는 「위원회에 의한 설계」를 가능한 한 없애려고 하고 있습니다. 대부분의 설계는 개개인이 하고 모두의 앞에 가지고 와서 개량해 나갑니다. 그래서 잘 되기도 합니다.

 

John Spicer는 프랑크푸르트 회의에서 export의 문제를 채택하여 제라고 말했습니다. 다른 무리도 말했다고 생각합니다. 그것은 좋은 예입니다. 그러나 그것으로부터 무엇인가 단 하나의 교훈인 듯한 것을 꺼낼 수는 없었습니다. 제가 export에 관해서 말하는 것은 너무 지나치게 규모를 확대하여 복수의 기술 안을 도입하는 것은 좋지 않을까라고 말한 것입니다. 물론 더 명확한 설계를 해야 합니다.




Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474

Bjarne Stroustrup Concept와 미래를 말하다 – 4 http://jacking.tistory.com/559

Bjarne Stroustrup Concept와 미래를 말하다 – 5  http://jacking.tistory.com/652

Bjarne Stroustrup Concept와 미래를 말하다 – 6  http://jacking.tistory.com/678

Bjarne Stroustrup Concept와 미래를 말하다 – 7  http://jacking.tistory.com/679

 



출처 : http://www.devx.com/cplus/Article/42448/0/page/1

저작자 표시
신고
by 흥배 2010.06.23 20:30

Page 4: Commitees and Standardization

 

Danny Kalev

당신은 몇 번이나 100명의 위원회라고 하는 것은 「혁신적인 설계에 최적인 장소는 아니다」라고 말하고 있습니다. ISO 표준화 위원회는 너무 사람이 많은 것은 아닌가요? RubyPhtyon은 「선 독재제」(역주:구현이 하나 밖에 없고, 기본적으로 단지 한 명이 독단으로 개발하고 있으며 그 구현이 그대로 사양이 되는 언어를 말하는 것)모델을 사용하여 표준화를 하고 있지요. Linux는 커뮤니티 프로세스군요. 더 무엇인가 지금의 시대에 맞는 다른 프로세스로 표준화 하는 것을 생각해 보면 어떻습니까? 지금 같이 쓸데없이 꼼꼼하고 불편한 것이 아닌 더 모두가 직접 참가할 수 있는 느낌으로

 

 

Bjarne stroustrup

저의 문서를 읽어봐 주세요. 표준화와 진화 모델에 대한 염려가 쓰여져 있습니다.HOPL3 paperHOPL2 paper. 그것은 차치하고 저는 「좀 더 모두가 직접 참가할 수 있다」라는 것이 향상으로 연결된다고는 생각되지 않아요. 언어의 논의에 있어서 보통「목소리」는 대체로 단기적인 것의 견해를 하고 있으며 유행에 좌지우지되고 있고 게다가 단 하나의 기능 밖에 생각하고 있지 않아요. 대부분이 「간단하고 완벽한 해결 방법」인지를 복잡한 문제에 적용할 수 있다고 믿고 있으며기존의 몇 십억 행의 코드、몇 백만 명의 프로그래머에 대한 교육이라고 하는 것에 대한 배려가 충분하지 않아요. 몇 년이나 참을성이 많고, 설계, 표준화를 위해 많은 귀찮은 세부를 명확하게 하는 일을 하고 싶은 사람은 거의 있지 않아요. 제가 본 곳은 「커뮤니티 프로젝트」라고 하는 것들은 이미 잘 알려진 개념이 존재하는 것밖에 유효하지 않아요. 예를 들어 Linux에 있어서의 Unix등이에요. 근본적으로 다른 설계 사상으로부터 추려 나누는 것은 어려운 일이에요. 그것과 C++의 표준화는 완전한 자원봉사 작업인 것을 알아 두어 주었으면 합니다. 만약 C++이 조금이라도 보수를 지불하게 되어 있으면 또 다른 물건이 되었을지도 모르죠.

저는 독재주의를 좋아하지 않지만 단기적으로 보면 효율적으로 선정을 푸는 것일 수도 있겠네요.하지만 제가 생각컨대 대부분의「선 독재자」라고 하는 것은 대체로 그 힘에 빠져서 일반에서 받아 들이지 않는 개인적인 취미의 기능을 넣거나 할 것입니다. 즉 제멋대로인 독단으로 달려버립니다.

 

C++에서는 독재라고 하는 것은 아직 전혀 행해지고 있지 않아요. 최초기를 지나면 단 하나의 구현은 존재하지 않아요. C++은 그 정도의 스크립트 언어와는 비교가 되지 않는 정도로 많은 기업의 근간에 짜 넣어져 왔습니다. 한층 더 1980연대 후반부터 1990연대에는 HPIBMIntelMicrosoftSun과 같은 기업은 단지 한 명의 독단에 좌우되는 언어를 착실한 비즈니스로 사용하고 싶다고는 생각하지 않았습니다. 여태껏 그렇다고 생각합니다. C++ 표준화의 일은 주요한 유저에 의해서 되고 있습니다.





Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474

Bjarne Stroustrup Concept와 미래를 말하다 – 4 http://jacking.tistory.com/559

Bjarne Stroustrup Concept와 미래를 말하다 – 5  http://jacking.tistory.com/652

Bjarne Stroustrup Concept와 미래를 말하다 – 6  http://jacking.tistory.com/678


저작자 표시
신고
by 흥배 2010.06.12 08:30

Danny Kalev

최근의 DDJ 기사에서 「ConceptC++0x의 근간을 이루는 신기능이다」라고 쓰고 있지요. 어떤 사람은 C++0x의 「주요 기능」이라고 단언했었어요(N2893. 그렇지만 Concept이 들어가지 않는다고 정한 것은 어쩐지 무정하네요. 예를 들면 Herb Sutter블로그에 쓰고 있습니다만 concept 연기에 관한 Web 상의 코멘트를 읽고 있으면 기술적인 부정확함은 물론이고 C++0xConcept이 들어가지 않는다고 하는 것은 굉장히 중대한 일이라고 생각하고 있는 것 같다. 이상한 일이다」라든가. 결국 Concept 어떻게 되도 상관 없는 것이네요. 어째서 이런 기능에 바보같이 시간과 일손을 소모했습니까?

 

 

Bjarne stroustrup

내가 썼던 것을 전부 인용하면

Concepttemplate의 사용을 보다 논리적으로 하거나 표준 라이브러리의 규격을 고쳐 쓰거나 하는 것에 근간을 이루는 신기능이며 또 제네릭 프로그래밍을 일반적으로도 사용할 수 있도록 하기 위한 주요한 기능이다.

이것은 단지

ConceptC++0x의 근간을 이루는 신기능이다」

라고 하는 것은 꽤 인상이 달라집니다.

그리고 저로서는 concept 자체를 「주요 기능」이라고 말하거나 하지 않았습니다. 그렇다고 하는 것도 어느 하나의 기능만을 가지고 그 언어의 「주요」라고 하는 등이라고 하는 것은 의미를 알 수 없습니다. 대부분의 사람에게 있어서 C++0x의 가장 중요한 신기능이란 병렬처리(concurrency)의 표준 지원이라고 생각하지 말세요. concept과 같이 taskatomic type 등을 직접 사용하는 것은 극히 일부의 프로그래머 뿐이지만 혜택을 받는 사람은 많습니다. C++0x의 개량은 보다 더 프로그램을 쓰거나 개발 환경을 만드는데 도움이 되는 툴에 중점을 두고 있습니다. 단지 그 기능 자체 뿐입이라고 잘라서 말할 수 있는 것은 아닙니다.

제가 생각컨대 concept이란 중요했고 또 장래도 중요하게 될 것입니다. 템플릿의 usability를 향상시켜 제네릭 프로그래밍의 범위를 펼쳐、고품질 라이브러리의 지원을 위한 중요한 기능입니다. 몇 십년의 장기적으로 봐도 중요합니다. 하지만 일반 프로그래머에 있어서 이 앞의 수년의 중요도라고 하는 것은 그만큼은 아닐 것입니다. 손을 쓸 수 없게 되기 전에 concept이 어쩔 수 없이 필요한 시대에 이르기 전에 개량한 concept을 넣을 수도 있을 것입니다.

장기적인 것의 견해가 중요합니다. 원래 Concept은 많은 C++0x의 개량점 중 하나 밖에 지나지 않는 것입니다. 비록 Concept이 없어도 C++0xC++98 보다 아득하게 뛰어난 툴이 될 것입니다.




Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474

Bjarne Stroustrup Concept와 미래를 말하다 – 4 http://jacking.tistory.com/559

Bjarne Stroustrup Concept와 미래를 말하다 – 5  http://jacking.tistory.com/652


저작자 표시
신고
by 흥배 2010.06.11 08:30

꼭 원 출처의 그림과 같이 보세요!!!

 

 

최신 게임에 있어서 캐릭터 애니메이션 제작은 어떤 것일까요?

6
1일에 오토 데스크가 주최한 「Autodesk Design Innovation Forum 2010」에서는 「언차티드 2」를 제작했던 Naughty Dog의 리드 캐릭터 기술 최고 책임자 Judd Simantov씨가 등장. Uncharted 2:Among Thieves (언차티드 황금 칼과 사라진 선단)에서의 캐릭터 애니메이션 파이프라인」이라고 제목을 붙인 강연을 실시했습니다.

「언차티드 2」에서는 여러 가지 오리지날 툴이 만들어서 MAYA와 제휴하는 것으로 부드러운 개발을 실현했다고 합니다.

 

캐릭터를 만들 때는 3개의 스켈톤이 준비되었다고 합니다. 실제 게임에서 사용하는 것, 애니메이션용, 모션 캡쳐용입니다만 Naughty Dog이 개발한 Rig 툴에서는 이것들을 통합적으로 관리할 수 있습니다. 템플릿을 조작하는 것만으로 간단하게 새로운 캐릭터를 작성 가능.

 

남성 캐릭터의 신체에 모두 공통의 스켈톤을 사용하고 있다고(얼굴은 개별의 것이 준비된다고) 합니다만 스켈톤을 수정했을 경우도 같은 템플릿으로부터 태어난 모든 캐릭터에 자동으로 적용되기 때문에 관리의 노력을 경감할 수 있다고 합니다. 스켈톤에 주석 텍스트를 붙이는 등 작업 환경을 커스텀마이즈 할 수도 있어 애니메이터 사이에서는 호평을 얻고 있다라는 것.

 

차례차례로 더해지는 변경을 어떻게 관리 할까는 고민거리입니다만 Naughty Dog에서는 이것에 전용 히스토리 툴을 준비하고 있습니다.

툴이 변경의 이력을 남겨 두는 것으로 아무리 복잡한 변경을 더해도 전의 모델을 간단하게 회복할 수 있다고 합니다. 게임 제작의 가혹함은 어느 곳이나 같은 것 같습니다. Simantov씨는 「출하 일주일 전이 되어 돌연 변경이 더해지기도 하기 때문에 이러한 툴은 도움이 됩니다」라고 유용성을 말했습니다.

게임 내에서는 상시 같은 모델이 사용되고 있는 것이 아닙니다. 원경 등 상세한 디테일을 필요로 하지 않는 경우는 처리를 고속화하기 위해서 간략화한 모델을 준비합니다만 Naughty Dog에서는 「LOD(레벨 오브 디테일)」라고 불리는 툴로부터 생성하고 있다고 합니다. 근경용의 하이 레조 모델이 있으면 간단하게 원경용 로우 레조모델을 작성 가능. 작업량의 경감에 한 역할 맡고 있다라는 것입니다.

대량으로 태어나는 애니메이션은 「애니메이션 라이브러리」에서 관리되고 있습니다. 몇 천의 애니메이션이 한 곳에 보존되고 있을 뿐만 아니라 누가 추가했는지 등도 알 수 있게 되어 있어 복수의 애니메이터가 있어도 데이터의 존재를 한눈에 알 수 있습니다.

애니메이션 라이브러리는 이름 등 여러 가지 조건으로 검색할 수 있어 애니메이션이 얼마나 도움이 되는가 하는 「유용도」라고 하는 척도도 준비되어 있다고 합니다.

모션 캡쳐는 정보량이 많기는 하지만 모든 프레임을 취급하는 것은 많은 노력이 필요하다고 합니다. 애니메이션 라이브러리에서는 모션 캡쳐 데이터로부터 필요한 움직임만을 가져오는 것이 가능하고, 트레이스 정도도 자유롭게 조정할 수 있다고 합니다.

「영화에서는 프레임 모두를 사용하지만 게임에서는 그렇게 하지 않는 것이 유용성은 높다」라고 하는 Simantov. 게임 제작의 현장에는 게임의 방법론에 맞춘 툴이 필요하게 되는 것 같습니다.

 

「장래적으로는 보다 리얼한 근육 시뮬레이션 시스템이나 MAYA 상에서 그린 동영상 스케치에 메모를 붙일 수 있는 스케치 툴을 만들고 싶다」라고 코멘트. 용도에 맞춘 툴을 정력적으로 개발하는 것으로 MAYA와의 제휴를 긴밀히 하여 한층 더 효율화를 도모해 간다라는 견해를 분명히 했습니다.

 

 

 

출처 : http://www.gamebusiness.jp/article.php?id=1686

 

 

저작자 표시
신고
by 흥배 2010.06.04 08:30

티스토리 툴바