5월 21일 오후 4시(현지시간) 미국 마운틴뷰에서 열리는 MBC 코리안 뮤직웨이브 콘서트에 최고의 한류 톱 가수들이 참가합니다. 미국에서 진행되는 콘서트이지만 유튜브를 통해 생중계 되어 전 세계 팬들이 감상할 수 있는데요, 추가적으로 본 콘서트에 출연하는 K-Pop 스타와의 특별한 시간을 마련했습니다.
콘서트 하루 전날인 20일 미국 서부 표준 시각으로 오후 4시부터 비스트가, 5시부터는 씨스타가 행아웃 온에어(Hangout On Air)로 전 세계 팬들이 볼 수 있는 생방송 인터뷰를 합니다. 유튜브 파워 유저이자 ‘글로벌 한국 문화 전도사’ 사이먼과 마티나(Simon & Martina)가 이번 행아웃 온에어 진행을 맡아 더욱 유쾌한 시간이 될 것 같습니다.
구글플러스 행아웃 온에어로 전세계로 생중계되는 비스트와 씨스타 인터뷰는 유튜브에서도 볼 수 있습니다. (비스트 공식 유튜브 채널과 씨스타 채널에서 각각 보실 수 있습니다.) 유튜브로 K-Pop 콘서트 라이브도 즐기고, 구글플러스로 비스트와 씨스타와의 라이브 만남도 가져 보시기 바랍니다. 구글플러스의 K-Pop 스타들을 서클에 추가해 실시간으로 소식도 받아보시기 바랍니다.
최근 런칭된 구글플러스 K-Pop 허브 페이지를 통해 K-Pop 한류 스타들과 국내외 팬들과 더욱 자주 만나고 교류하기를 기대합니다.
난 페이스북에 대해 오래전 부터 비판적 견해를 견지 해왔지만, 마크 주커버그가 상장을 위한 투자자들에게 보낸 편지 중 일부에 적힌 내용은 꽤 진지하게 들어볼만한 대목이다. (한국어 번역본)
강한 회사를 만드는 방법의 하나로, 우리는 페이스북을 훌륭한 인재들이 세상에 영향을 끼치고 서로 배울 수 있는 공간으로 만들기 위해 최선을 다하고 있습니다. 우리는 우리만의 고유한 문화와 경영방식을 계발해 왔으며, 우리는 이를 해커웨이 (Hacker Way)라고 부릅니다. (중략) 해커방식은 끊임없는 개선과 이터레이션* 방식을 포함합니다. 해커들은 언제나 더 개선될 수 있고, 완성이란 있을 수 없다고 믿습니다. (잘못된 것이 있으면)꼭 고쳐야 합니다. 종종 '그건 안돼' 혹은 '이정도면 됐잖아' 라고 말하는 사람들 에 맞서서. (중략) 그리고 해킹은 원래 직접 해보는 능동적인 연습입니다. 새로운 아이디어가 (실현)가능한지, 혹은 뭔가 만드는 최선의 방법이 무엇인지 며칠동안 토론하는 대신, 해커들은 차라리 그냥 프로토타입을 만들어 무엇이 잘되는지 확인합니다. 패이스북에서 자주 듣는 해커들의 문구가 있습니다: "코드가 논쟁보다 낫다."
마이크로소프트와 구글 및 아마존에 이어 기술 플랫폼 기업으로 페이스북의 면모를 보여 주는 대목이다. 개발자의 아이디어 구현이 바로 서비스가 되는 생산적인 효과를 얻으려면 내부의 자산이 기술 플랫폼화 되어 있어야 한다.
성공한 플랫폼 기업의 특징은 내부에 단일화된 플랫폼을 만들고 이를 손쉽게 접근하여 구현할 수 있는 인터페이스가 존재한다. 마이크로소프트느 윈도우, 구글은 검색 엔진, 페이스북은 소셜네트웍을 기술플랫폼화 시키는데 성공했다. 너무 많은 단일 서비스를 각자 따로 만드는 노동 집약적 IT 기업은 모멘텀을 계속 만들지 않는 한 쉽게 살아남기 힘들다는 것을 반증한다.
기업 내부 뿐만 아니라 외부와의 관계에서도 마찬가지이다. 포털 업체를 비롯한 대부분 IT 업체의 사고 방식은 우리가 다 만들어 주는 것만 쓰라는 '서비스주의'가 강한데 반해 외국에서는 가진 것을 밖에 나눠주고 같이 만들어 성공하는 '플랫폼 주의'가 더 활성화되어 있다.
플랫폼주의적 사고는 국내에서 시장 규모와 시장 처리를 하는 효율성 측면에서 항상 반론에 부딪힌다. 플랫폼을 열어두어도 누가 쓰겠나? 누가 만들어주겠나? 차라리 그 시간에 우리가 하고 말지 이런 비판이다. 그러다 보니 우리나라는 대기업의 문어발식 확장에 익숙해지고 비지니스 생태계는 늘 피폐해진다.
다시 페이스북 이야기로 되돌아와서... 이를 밑에서 부터 실행한 것이 바로 해커톤이다. 90년대말 이후 개발자 커뮤니티의 행사였던 포맷을 기업에 성공적으로 차용한 모델이다. (참고: 인사이드페이스북: 해커톤 이야기)
이 방법을 독려하기 위해, 우리는 모든 사람이 자기가 가지고 있는 새로운 아이디어를 만들어볼 수 있는 해커톤(개발자, 디자이너등이 모여 몇일동안 (보통 2-3일정도) 프로토타입 개발을 행사)을 몇 개월마다 갖습니다. 마지막에 모든 팀이 함께 모여 만든 것을 들여다봅니다. 우리의 성공한 프로덕중 많은 것들이 이 해커톤에서 만들어졌습니다. 타임라인, 체팅, 비디오, 모바일 개발 프래임웍 그리고 HipHop컴파일러같은 중요한 인프라가 여기 포함됩니다.
우리의 모든 엔지니어가 확실히 이 방법을 공유하도록, 모든 새로운 엔지니어들은 -코드를 짤 필요가 없는 매니저들도 포함해서- 페이스북 코드베이스와 툴, 그리고 해커방식을 을 배울 수 있는 '부트캠프' 에 참가해야 합니다. 우리 분야에는 엔지니어들을 관리하지만 코드를 직접 짜고싶어하지는 않는 사람들이 많습니다. 하지만 우리가 원하는 사람은 이 부트캠프를 할수있고, 하고싶어하는 사람들입니다.
페이스북의 "좋아요(Like)" 버튼도 사내 해커톤에서 나온 결과물이며, 기업공개(IPO)가 있는 전날 직원들이 이를 기념하기 위해 1박 2일 해커톤을 열고 개발을 하며 하루를 회사에서 보낸다고 한다. 이를 보면 얼마나 해커톤이 페이스북 문화에서 중요한 역할을 하고 있는지 알수 있을 것 같다. 우리 회사도 얼마전 비슷한 행사를 열기도 했다. (Daum人 해커톤: 즐거운 상상의 나래를 펼치다)
물론 페이스북에 대한 거품 논란도 뜨겁다. 사용자는 급격히 느는데 반해 실적은 그다지 가파르지 않고, 미국 3위 광고주인 GM이 페북 광고 효과에 의문을 제기하고 올해 광고 집행을 하지 않기로 결정했을 뿐 아니라 스폰서 광고 자체가 어려운 모바일에서 페이스북 쓰는 비중이 점점 늘고 있기 때문이다.
일반인들도 페이스북이 지속적으로 성공할 것인가`라는 설문 조사에 46%가 `새로운 것이 등장하면 점차 사라질 것`이며 천억달러를 웃도는 기업 가치에 대해선 응답자 50%가 과도하다고 답했다. 게다가 얼마전 1조원의 인스타그램 인수까지 거품 논란은 최정점에 달해 있다.
페이스북이 마크 주커버그라는 1인에 의해 독단적으로 회사가 운영될 수 있는 지배구조도 문제이다. 이사회나 주주의 어떤한 견제가 없이 기업이 장기 생존하기 어렵기 때문이다.
특히나, 최근 들어 페이스북의 국내 성장세가 놀랍다. 소셜웹의 대세가 계속 되고 있는 상황인데다 더 많은 커뮤니케이션이 블로그에서 트위터로 그리고 페이스북으로 옮겨가고 있는 모양세다. 국내 기업들에게도 페이스북이 더 이상 파트너가 아닌 경쟁자로 인식될 수 밖에 없다.
페이스북의 현재 사용자수는 9억명이다. 연말에는 10억명을 돌파할 예정이라니 곧 세계 최고 인구를 가진 온라인 국가가 탄생하는 것이다. 아이러브스쿨과 싸이월드 열풍을 경험한 우리로서는 소셜네트웍이 가진 네트웍 효과와 파급력은 이미 알고 있지만, 전 세계적인 실험이 어떻게 끝날지 궁금하다.
하지만, 페이스북이 가진 Hacker's Way가 잘 유지된다면 구글이나 아마존, 이베이 등 웹 플랫폼을 완성하고 이를 통해 장기간 생존할 수 있는 기업으로 발전해 나갈 가능성이 더 커졌다고 본다. (2006년 당시 페이스북, 제2의 아이러브스쿨 될까?라는 의문으로 시작하여 페이스북(Facebook)의 '가짜' 개방의 면모에도 변화를 준다면 더 좋겠다만...)
위대한 위산이라는 영화를 보면 주인공이 어릴 때 잠깐 그림을 그리다가 다 포기하고 어부로 돌아간다. 그러다 느닷없이 스폰서가 붙어서 십년쯤 뒤에 다시 그림을 그리는데 그림 실력이 전혀 줄지 않은 장면이 나온다. 한국 예고나 미대 출신들은 이 장면을 보고 영화에서 뻥을 친다고 생각을 하겠지만, 그건 늬들이 그림을 근육으로 그리기 때문에 발생하는 문제일 뿐. 내가 권옥연과 김환기를 비교했을 때도 말했지만, 마음으로 그리는 그림은 기복이 없으며 수십년이 지나도 그 감각이 퇴화되지 않는다. 하지만 근육으로 그리는 그림은 기복이 존나게 심하며 몇 주만 지나도 감각이 쇠퇴해 버린다.그래서 훌륭한 화가들은 언제나 제자들에게.......
뉴아이패드에는 기존에 쓰던 애플 블루투스 키보드를 사용하기로 해서, 아이패드1 용으로 블투 키보드를 하나 장만하기로 했다.
아이락스 BT-6460이 평가가 좋은 키보드에 속해서 이것으로 구매했다.
구매 시에 웃겼던 것은 - 인터파크에서는 검정이 디폴트로 되어 있고, 다른 색상을 선택하면 추가금을 내야 하는데, 옥션에서는 흰색이 디폴트로 되어 있고 다른 색을 선택하면 추가금을 내야 했다. 아내가 흰색을 선호하므로 옥션에서 구매했다. (덕분에 옥션 해킹 사태 이후 처음 옥션에서 구매를...)
키감은 나쁘지 않은 편이다. 애플 쪽이 낫긴 하지만 가격 차이가 워낙 크니까 비교의 의미가 없다.
키보드 크기가 애플 것보다도 작다. 손이 큰 사람은 조금 불편할지도 모른다. (나는 별 상관없었지만 어차피 내가 쓸 것도 아니다.)
건전지는 AAA 2개가 들어가는데, 동봉되어 왔다.
건전지가 다 되면 불빛으로 알려준다고 하는데, 이 점은 마음에 든다. 애플은 입력이 버벅되기 시작해야 알 수 있다.
크기가 더 작아서 애플 것보다 더 가벼운 것 같다. (재보진 않았다.)
온오프 스위치가 하단에 따로 있는데, 이렇게 만들어두니까 애플 것처럼 가방 안에서 저절로 눌려서 켜지거나 하는 일은 없을 것 같다. 이 점도 마음에 든다.
애플 키보드에서 지원하는 아이패드 단축키가 작동이 안 되지만 어차피 안 쓰니까 상관없다. (이 단축키는 화면밝기, 음악듣기, 사운드 조정 등을 말한다.)
Del키가 백스페이스키와 똑같이 작동하지만 애플 키보드에 익숙해지면 그러려니 한다.
한자키나 한영키가 안 먹지만 이것도 그러려니... (쳇)
제일 아쉬운 점은, 키 배열이다.
특히 우측 키배열이 마음에 들지 않는다. 애플의 경우 이동키(화살표키)의 크기를 줄여서 귀퉁이에 몰아넣었고, 그 위에 우측 쉬프트키가 시원하게 빠져있다. 내 경우 쉬프트키는 좌측은 거의 사용하지 않고 우측 것만 애용하기 때문에 이런 배치가 아주 마음에 든다. 그런데 아이락스의 경우는 우측 쉬프트키가 일반 키 크기 정도에 그 옆에 위 이동키가 있고 그 다음에는 FN(펑션)키가 있다. 이것은 이동키가 다른 키와 같은 크기를 갖기 때문이다. 애플의 키배열 방식은지금은 웬만한 노트북도 다 따라하고(사실 애플이 먼저 한 건지는 모른다. 내가 본 기억으로는 그렇긴 하지만...) 있는데, 이런 부분에 신경을 써주었다면 정말 좋았을 것이다.
사실 애플도 과거에는 이동키를 일렬로 배열한 키보드를 내놓아서 욕 먹은 일이 있다. 있으나마나한 이동키였다고 할까...
안녕하세요. 迪倫입니다. 오늘은 제 글이 아니라 "밥과술"님의 글을 대신 소개합니다.
저는 주로 역사나 영화에 대해 블로그를 하고 있습니다만, 역사란 것도 결국 사람이 먹고 살던 얘기가 아닌가 해서 종종 먹는얘기를 "진지하게" 다루기도 하고 있습니다. 음식 밸리.... 글 전체보기
Joshua Bloch에 대해서는 Effective Java에 관한 글에서 소개한 적이 있지만, 굳이 여기서 다시 언급할 필요도 없다고 생각합니다. Java의 주요 클래스 라이브러리들의 설계를 주도하여, Java의 API 설계 품질의 기준을 한층 끌어올린 그는, API 설계에 관해 전문가라고 해도 충분하다고 생각합니다.
이 강연의 주제는 제목 그대로 좋은 API를 설계하는 방법과 그 중요성에 대한 강연이고, 제가 아는 한 API 설계에 관한 대부분의 중요한 생각들을 담고 있다고 생각합니다. 그 생각들을 전달하는 면에 있어서도 매우 훌륭한 강연이기에 만약 아직 이 강연을 보신 적이 없으신 분들은 시간을 들여 직접 보실 가치가 있으리라고 생각합니다. 이 글에서는 주로 API의 설계 과정에 대한 내용에 대해 제가 현재 시점에서 인상적인 부분들에 대한 의견을 적어봅니다.
If you program, you are an API designer
예전에는 프로그래머들을 API 설계 경험이 있는 프로그래머와 그렇지 않은 프로그래머로 분류할 수 있다고 생각했습니다. API 설계를 하기 전에는 다른 프로그래머가 어떤 도메인에 대해서 어떤 생각을 가지고 있을지, 주어진 API를 사용할 때 얼마나 실수할 수 있을지, 주어진 API가 얼마나 이해하기 쉬울지에 대해서 고민해보지 않았으니까요. 그리고, 그러한 고민들을 통해서 문제들을 해결하는 방법을 깨닫는 과정이 중요하다고 생각했습니다. API 설계를 경험하고나서 제가 느낀 것은 학부 시절에 Automata 수업을 들었을 때의 느낌이었죠.
그런데, Joshua Bloch은 모든 프로그래머는 API 디자이너라고 얘기합니다. 이 말을 듣고 다시 생각해보니, 실제로는 모든 프로그래머는 자신이 만든 코드를 사용할 모든 사용자 – 즉, 최종 사용자 (end-user)이거나 다른 프로그래머들을 고려하지 않으면 안된다는 것을 깨달았습니다. 어쩌면 그만큼 프로그래머에 대한 잣대가 올라갔다는 생각도 듭니다.
Start with Short Spec–1 Page is Ideal
API 설계의 시작 단계에서는 기민성(agility)이 완전성( completeness)보다 중요하다는 이야기입니다. API 설계의 시작 단계에서는 실제로 그 API를 들고 사용자에게 부딪혀보지 않으면 그 API가 요구사항에 적합한지 알 수 없는데, 이해하기도 힘든 복잡한 API 스펙을 가지고는 사용자들이 이해하기도 힘들고, 변경하기도 힘들다는 것입니다. 일반적인 소프트웨어 개발은 기민성을 중요시하면서도 API 설계에 있어서는 기민성과 완전성 사이에서 저울질 하기가 어려운 면이 있었는데, 한 페이지라는 기준은 매우 훌륭한 기준인 것 같습니다. 그리고, 이 한 페이지를 들고 사용자와 부딪혀보는 과정들 (이를테면, Hallway testing) 도 매우 중요하게 여겨집니다.
When in doubt leave it out
API의 어떤 요소 (메서드, 파라미터, …)가 들어가야 할지 말기 고민된다면, 빼버리라는 것입니다. 이미 다른 사람들이 사용하는 API는 없애기 힘들지만, 추가하기는 쉬운 API의 특성에 기인하는 매우 중요한 특성입니다. 요구사항을 다른 부서 등과 조율하는 과정에서 애매모호한 기능 요구사항들이 항상 나타나는데 이에 대한 명확한 결정을 내리는 것이 가장 좋긴 하겠지만, 그렇지 못하는 경우도 흔히 벌어지는 일인 것 같습니다. 이 때, API의 이러한 특성은 요구사항의 결정에서도 중요한 근거가 될 수 있지 않을까 하는 생각이 드네요.
Write to Your API Early and Often
API 설계에서 가장 흔하게 겪고, 또 가장 중요한 문제점으로 드러나는 것은, API를 이용한 구현하는 도중에 특정 기능을 충족할 수 없음을 발견하는 것일겁니다. 기민한 개발 과정으로 볼 수도 있겠지만, API 사용자 입장에서는 부족한 API 설계 상의 문제를 파악하거나 API가 동작하지 않는 문제를 발견하는 것, 그리고 변경된 API를 적용하는 과정들은 매우 힘들고 비용이 많이 들 뿐만 아니라 괴로운 과정입니다. 이러한 문제들의 대부분은 결국 API를 이용해서 구체적인 프로그램을 만들어보는 것 밖에는 방법이 없고, 기본적으로 이 역할을 API 설계자에게 있어야 합니다. TDD를 한번이라도 해보신 분들은 아시겠지만, API를 사용하는 코드를 먼저 써보는 것은 API 설계에 커다란 도움이 됩니다. 그리고 이러한 과정에서 만들어진 API 예제를 사용자에게 제공하는 것은 API를 사용하는 방법을 쉽게 익힐 수 있도록 도와줄 뿐만 아니라 API 사용자들이 잘못된 사용 방법에 빠지지 않도록 도와줍니다. Joshua는 API 설계 시의 API 예제가 API를 사용하는 모든 코드 중에 가장 중요한 코드라고 얘기합니다. 이는 절대 과장이 아니라고 생각합니다. API 예제가 제공되지 않는 API를 직접 개발하거나 사용해본 입장에서 이 부분이 뼈저리게 느껴지는군요.
Document Religiously
API라고 한다면 가장 좋은 문서화가 요구되어야 하는 것은 당연한 것 같습니다. 하지만, 문서가 없는 API를 종종 봅니다. 저도 잘못된 내용의 문서화가 된 API를 쓰거나, 모든 측면의 문서화를 하지 않은 등의 실수들이 떠오릅니다. 문서화에는 정말 ‘Religiously’라는 단어 – 우리말로 굳이 옮긴다면 ‘열광적으로’ 라고 해야할까요 – 를 써야할 정도로 개발자가 그만큼 공을 들이지 않으면 안되는 것 같습니다.
Closing
이 강연은 비록 5년 전의 내용이지만, API의 설계 과정 뿐만 아니라, 일반적인 API 설계 원리, 클래스, 메서드, 익셉션의 설계에 관한 내용들을 담고 있으므로, 현재는 물론 앞으로도 계속 곱씹을 수 있는 내용이라고 생각합니다. 다시금 말씀드리지만, 한번씩은 보시기를 권해드립니다. 가능하다면, 누군가가 자막 번역을 해준다면 좋겠다는 생각이 드는군요.
제게는 API 설계에 대해서 예전에 했던 생각들을 더올리게 되면서 현재 직면하고 있는 문제들에 대해서도 새롭게 많은 고민들을 할 수 있게 해주는 강연이었습니다. 좋은 강연에 대해서 Joshua Bloch에게 감사드립니다.
구글플러스 모바일 앱 출시*와 더불어 K-Pop 허브 페이지를 오픈 했습니다! 이제 애프터스쿨, 비스트, 씨스타, 인피니트...등 전세계 팬들의 사랑을 받는 K-Pop 스타들을 구글플러스에서 만날 수 있습니다.
오늘 첫 공개한 K-Pop 허브 페이지는 한국어 뿐 아니라 영어와 일본어로도 제공이 되어 국내외 팬들이 K-Pop 정보를 한눈에 볼 수 있도록 했습니다. 또한 여러군데 흩어져있던 K-Pop 그룹들의 활동 내용, 멤버 프로필, 각종 일정 및 이벤트, 팬미팅 일정, 사진과 동영상 그리고 각 멤버들의 개인 페이지들도 한꺼번에 볼 수 있습니다. 좋아하는 그룹이나 그룹 멤버들을 클릭 한번으로 아주 간단히 서클에 추가해 화상 채팅 기능인 행아웃을 통한 팬미팅에도 참석할 수 있고, K-Pop 스타들이 직접 전하는 따끈따끈한 소식을 바로바로 들을 수 있습니다.
지난 4월에는 인피니트가 일본에서 국내 팬들과 구글플러스 행아웃으로 팬미팅을 진행했고, 5월에는 씨스타의 행아웃 온에어 팬미팅이 실시간으로 중계되기도 했습니다. 구글플러스에서는 스타와 팬들과의 특별한 만남이 이루어질뿐 아니라 팬들끼리도 서로 소식을 교류하며 교감을 나눌 수 있습니다. 해외 팬들을 위해 K-Pop 스타의 한국어 포스팅을 영어로 번역해 제공하기도 합니다.
물론(!) K-Pop 허브에서 만나볼 수 있는 스타들은 앞으로 계속 늘어날 것입니다. 많이 기대해주시기 바랍니다.
끝으로, 현재 구글플러스에서 만날 수 있는 K-pop 스타 서클을 공유합니다. 지금 바로 서클에 추가해 구글플러스에서 K-pop 스타와 이야기해 보세요!
*구글플러스 모바일 앱은 구글 플레이 스토어(구 안드로이드 마켓)과 앱스토어에서 다운받을 수 있습니다.
Twitter에서 열심히 놀던 중에, 고수님이신 @zerocool_kor 님께서 아래와 같은 트윗을 날리셨습니다.
저는 물론 다 알고 계실분이 왜 이런 질문을 올리실까 하면서 FLUSHDB 라는 명령을 언급했습니다. Redis 에는 FLUSHDB라는 명령이 전체 데이터를 삭제하는 기능을 합니다.
그런데 다음과 같은 내용을 알려주시는 겁니다. 역시나 직접 테스트 다 해보시고 이상한 동작을 문의하신거죠.
그렇습니다. FLUSHDB를 하는 동안 다른 redis의 동작이 대기하는 현상이 있는 것입니다. 사실 이것은 Redis 구조상 아주 당연한 일입니다. 왜냐하면 간단하게 설명하면 Redis 가 싱글 스레드로 동작하기 때문입니다. Memcached도 마찬가지입니다. 다만 Memcached의 경우는 실제로는 멀티 스레드인데, 데이터에 접근하는 부분은 Mutex로 인해서 동기화되어서, Command 파싱까지는 멀티 스레드가 실제 데이터의 읽기 등은 전부 싱글 스레드처럼 동기화되어서 동작하게 됩니다.( 똑똑하신 분들은 이건 실제 싱글 스레드처럼 동작하는 serialization 이 아니라고도 하시지만 전 무식해서 그냥 이렇게 설명합니다.) 그래서 redis, memcached의 경우, 시간을 많이 먹는 단일 작업이 들어가면 전체적으로 성능이 떨어지는 것을 체감하시게 됩니다.
그래서 제가 다음과 같은 답변을 드립니다. 실제 싱글 스레드이므로 다른 동작이 블록되는 것이 맞는듯 합니다. 다만 워낙 동작이 달라서, 해당 지연이 눈에 띄지 않는 것이라는 내용입니다.(물론 이건 다시 정리한 표현이니 다르다고 돌은 던지지 마세요.)
Redis에서 약 200만개의 데이터를 임시로 넣어두고, 추가로 200만개를 넣으면서 FLUSHDB 명령을 날리니 약 1.1초 정도의 시간이 걸리고 그 동안에 블록이 되는 것을 볼 수 있었습니다. 시간 자체는 크게 의미를 가지지 마시기 바랍니다. 장비마다 다 틀립니다. 여기서 사용한 코드는 다음과 같습니다.
import redis
r = redis.StrictRedis( host='127.0.0.1', port=1212 )
for i in xrange(0,4000000):
r.set( str(i), str(i) )
print i
그런데 재미있는 것은 같은 싱글 스레드 구조인 memcached 에서는 이런 지연이 없다는 것입니다. 즉, flush_all 이라는 명령을 주면 데이터가 바로 사라집니다. 왜 이런 차이가 있는 것일까요? 무지무지하게 궁금하지 않습니까?(안 궁금하시면 저만 알고 넘어가도록, 퍽퍽퍽!!!)
일단 힌트는 고수이신 @zerocool_kor 님이 말씀해주십니다.
네 그렇습니다. Memcached는 flush_all 이 들어온 시점에 데이터를 지우지 않습니다. 나중에 get 을 할 때, 발견하고 지워버리는 거죠. 간단하죠? 믿을 수 없다라는 분들을 위해서 이제 소스로 설명을 드리겠습니다. 먼저 Redis 부터 보시죠. Redis는 2.4.13 버전을 기준으로 합니다.
Redis의 db.c 파일의 198 라인에 flushdbCommand 라는 함수가 있습니다. 이 함수를 보시면 그냥 간단히 다음과 같습니다.
다시 _dictClear 함수를 봅니다. Dict.c의 358 라인에 있습니다. 소스를 보시면 루프를 돌면서 하나씩 제거해가는게 보입니다. 이게 200만개를 지우는 거죠.
int _dictClear(dict *d, dictht *ht)
{
unsigned long i;
/* Free all the elements */
for (i = 0; i < ht->size && ht->used > 0; i++) {
dictEntry *he, *nextHe;
if ((he = ht->table[i]) == NULL) continue;
while(he) {
nextHe = he->next;
dictFreeEntryKey(d, he);
dictFreeEntryVal(d, he);
zfree(he);
ht->used--;
he = nextHe;
}
}
/* Free the table and the allocated cache structure */
zfree(ht->table);
/* Re-initialize the table */
_dictReset(ht);
return DICT_OK; /* never fails */
간단히 정리하면 다음과 같은 순서로 흘러갑니다.
이제 memcached 의 소스를 봐야합니다. 뭐 이것은 두 부분을 봐야 하는데요. 먼저 flush_all을 통해서 어떤 동작이 일어나는지 알아보도록 하겠습니다. 이것도 간단합니다. Memcached는 1.4.13 버전을 기준으로 합니다.
Memcached.c 의 3290 라인을 살펴봅니다. 이 코드는 static void process_command(conn *c, char *command) 라는 함수 안에 존재합니다. 중요한 부분만 발췌하면, settings.oldest_live 가 셋팅되는 부분만 보면 됩니다. 이게 뭐하는 거냐 하면, flush_all 이 들어온 시간을 기록해둡니다. 아까 @zerocool_kor 님의 멘션을 기억하세요. 기준 시간을 정해놓고 이거 이전께 들어오면 그냥 다 NULL 입니다. 이러는 겁니다. 참 쉽죠잉?
time_t exptime = 0;
set_noreply_maybe(c, tokens, ntokens);
pthread_mutex_lock(&c->thread->stats.mutex);
c->thread->stats.flush_cmds++;
pthread_mutex_unlock(&c->thread->stats.mutex);
if(ntokens == (c->noreply ? 3 : 2)) {
settings.oldest_live = current_time - 1;
item_flush_expired();
out_string(c, "OK");
return;
}
exptime = strtol(tokens[1].value, NULL, 10);
if(errno == ERANGE) {
out_string(c, "CLIENT_ERROR bad command line format");
return;
}
/*
If exptime is zero realtime() would return zero too, and
realtime(exptime) - 1 would overflow to the max unsigned
value. So we process exptime == 0 the same way we do when
no delay is given at all.
*/
if (exptime > 0)
settings.oldest_live = realtime(exptime) - 1;
else /* exptime == 0 */
settings.oldest_live = current_time - 1;
item_flush_expired();
out_string(c, "OK");
return;
이제 실제로 get 할 때 어떻게 될 것인가를 봐야합니다. 이것 저것 다 빼고나면 실제로 items.c의 483라인의 do_item_get 이라는 함수가 호출됩니다.
못 믿기시겠다는 분은 gdb로 디버깅 걸어보시면 됩니다. Gdb 설명은 생략합니다. 다음이 해당 함수의 소스입니다. 참 길죠잉?
item *do_item_get(const char *key, const size_t nkey, const uint32_t hv) {
mutex_lock(&cache_lock);
item *it = assoc_find(key, nkey, hv);
if (it != NULL) {
refcount_incr(&it->refcount);
/* Optimization for slab reassignment. prevents popular items from
* jamming in busy wait. Can only do this here to satisfy lock order
* of item_lock, cache_lock, slabs_lock. */
if (slab_rebalance_signal &&
((void *)it >= slab_rebal.slab_start && (void *)it < slab_rebal.slab_end)) {
do_item_unlink_nolock(it, hv);
do_item_remove(it);
it = NULL;
}
}
pthread_mutex_unlock(&cache_lock);
int was_found = 0;
if (settings.verbose > 2) {
if (it == NULL) {
fprintf(stderr, "> NOT FOUND %s", key);
} else {
fprintf(stderr, "> FOUND KEY %s", ITEM_key(it));
was_found++;
}
}
if (it != NULL) {
if (settings.oldest_live != 0 && settings.oldest_live <= current_time &&
it->time <= settings.oldest_live) {
do_item_unlink(it, hv);
do_item_remove(it);
it = NULL;
if (was_found) {
fprintf(stderr, " -nuked by flush");
}
} else if (it->exptime != 0 && it->exptime <= current_time) {
do_item_unlink(it, hv);
do_item_remove(it);
it = NULL;
if (was_found) {
fprintf(stderr, " -nuked by expire");
}
} else {
it->it_flags |= ITEM_FETCHED;
DEBUG_REFCNT(it, '+');
}
}
if (settings.verbose > 2)
fprintf(stderr, "\n");
return it;
}
보면 settings.oldest_live 가 current_time(현재시간) 보다 적고, 0이 아니라는 것은 한번 이상 flush_all이 실행되었다는 뜻입니다. 해당 초기값이 0이거든요. 그리고 발견된 item의 시간과 oldest_live를 비교하면, 해당 key가 flush_all 이전인지 이후인지 판단이 가능하겠죠? 그래서 memcached 에서는 실제로 아이템이 지워지는 시간이 거의 없는 것 처럼 느껴지는 겁니다.
그러나 뭐든지 장점과 단점이 있는 법!!!, memcached는 실제 키를 찾고 값을 비교하고 expire time이 지난 뒤에 삭제하는 형태이므로, get이 기존보다 조금 느려지게 됩니다. 뭐 그래도 엄청 빠니, 크게 신경을 안 써도 된다는 장점도 있습니다.
그럼 우리의 궁금점은 왜 -_-, why, 어째서, how come!!! Redis는 일일이 다 삭제하는 코드를 만든 것일까요? Redis 개발자가 memcached 개발자보다 덜똑똑해서( 물론, memcached 개발자가 괴물인건 분명합니다 1980년 생인데, 무슨 초천재를 보는듯한 T.T 난 뭐했나!!!) 일까요?
저는 개인적으로 redis 와 memcached의 구조적인 차이 때문이라고 생각합니다. Memcached 가 캐시 자체에만 집중했다면, 그래서 메모리를 관리하는 구조도 서로 다릅니다. Memcached는 slab 할당과 chunk 구조를 이용합니다. 반대로 Redis는 pub/sub 등의 기능과 key의 변경을 noti 받는 기능이 있습니다. 그래서 실제 flush가 되기 전에 이런 키들에 대해서 키가 삭제된다는 알람을 줘야 합니다. 해당 코드가 아까 살짝 넘어간 signalFlushedDb 라는 함수입니다. 그래서 어느 구조가 더 좋다라고 말할 수 없을 것 같습니다. 그래서 조금이라도 처리속도가 느려지면 안되는 경우에 Redis의 FLUSHDB는 위험할 수도 있습니다.
여담으로, Redis는 싱글 스레드다라고 말하면 안믿는 분들이 계십니다. 그럼 백그라운드로 메모리를 백업하는 BGSAVE는 어떻게 만들어진거냐!!! 말도 안된다라는 분들에게 한마디 하자면, BGSAVE는 fork 한 후에 child Process 가 처리해주는 겁니다. 속지마세요. 코드가 궁금하신 분은 rdb.c의 499라인을 보시면 됩니다.
구글 사무실에 직접 방문해 참여하지 않더라도 집에서, 공원에서, 까페에서, 학교나 사무실 등 어디서나 참여할 수 있습니다. PC로 구글 플러스에 로그인 한 다음 구글 코리아 페이지를 방문하시면 스트림에서 행아웃 온에어 포스팅을 확인하실 수 있습니다.
또한 구글코리아의 구글플러스 행아웃(실시간 화상채팅)에 참여를 원하시는 분은 ilovegkorea@gmail.com으로 이메일을 보내주시기 바랍니다. 행아웃 일반인 참여자를 8분까지 선정해 초청장을 보내드리겠습니다. 또한 구글플러스에 누구나 라만 박사에게 질문을 남겨주시면 강의때 답을 해드리겠습니다. 해쉬태그 '#라만박사특강' 을 달아 질문을 남겨 주세요!
14세때 녹내장으로 시력을 잃은 라만 박사님은 구글 연구과학자로, 아이즈 프리 모바일 인터페이스 설계, 청각 상호작용 및 웹 표준 등 접근성 분야의 선도적인 전문가로, 16년동안 웹 접근성을 연구해 왔습니다. 구글에는 2005년 입사해 웹 접근성 향상을 위한 연구를 이끌고 있습니다.
이 소식을 구글 플러스로 주변 사람들과 공유해 보세요! 그럼 많은 관심과 참여 부탁드립니다.
Help is a drug company that offers you less. Less active ingredients, less waste, less confusion, less greed. Its tongue-in-cheek website has a map of its latest sales data called "What's wrong U.S.?" A bar chart for each state shows how many people are buying products for particular maladies.
So why are the inner northwest states having problems sleeping? My guess they're up late worrying about gay marriage.
2.
후배한테 전화 왔음. "블로그에 적은 쇠말뚝 이야기는 엉터리라는 게 레알 사실임?"이라고...-_-;;
3.
이 이야기의 전개는 대강 이렇다.
낚인 사람 : 그럼 누가 산에다 쇠말뚝을 박았음?
정상 사람 : 측량용으로 박았다는 게 대세지만...
낚인 사람 : 측량용 쇠말뚝은 그렇게 안 생겼음!
(여기서 조금 파고 들어가면 측량용 쇠말뚝이라는 걸 본 적이 없다는 사실이 밝혀짐)
정상 사람 : 측량용 뿐만 아니라 무속인들이 박은 것도 있고, 군대에서 시설 설치한다고 박은 것도 있다고 함.
낚인 사람 : 그러니까 누가 무엇 때문에 왜 박았는지 6하원칙으로 설명하셈!
정상 사람 : 아니, 그게 문제가 아니고, 일제가 박았다는 증거는 어디 있삼?
낚인 사람 : 일본 놈들이 얼마나 철저한 놈들인데 증거를 남겨 놓았겠음? 다 없애버렸지!
정상 사람 : 그럼 어떻게 일제가 박은 건지 알 수 있삼?
낚인 사람 : 그것들은 원래 나쁜 놈들이잖아! 너 왜 자꾸 나쁜 놈 옹호함?
정상 사람 : 증거도 없는데 나쁜 사람이라고 덮어 씌우는 게 나쁜 거 아님?
낚인 사람 : 이런 친일파, 매국노!
(대화 끝....)
나는 외래에 오지 않는 동안 몇번 그녀에게 전화를 했었다. 어렵사리
치료가 잘 되고 있는데 환자가 외래에 오지 않으니 말이다. 병원 전화를 안받는 건지 연락이 안되었다.
그녀가 다시 외래를 찾던 날
부랴부랴 CT를 다시 찍고 바로 치료를 시작했다.
그날의 일에 대해 그녀가 편지를 썼다.
당장 치료를 하자는 말에 왠지 용기가 났다고 했다.
주위에 3개월, 6개월
선고를 받은 환우들이 많았는데,
내가 서둘러 치료를 하자고 하니 왠지 용기와 희망이 생겼다고 했다.
물론 나도 환자가 다시 외래에 오던 날이 기억난다. 마음 속으로 화가
많이 났었다. 좋은 약으로 치료를 하고 있었고 반응도 좋았는데 그 후로 몇 개월이 지나버렸으니 이제
그 약을 다시 쓸수가 없다. 보험적용도
안되고 그 사이에 그 약제에 대한 저항성도 생겼을 것이다. 그래서 원래 효과를 보았던 좋은 약보다 훨씬
독한 약으로 치료를 해야 했기 때문에 화가 나지 않을 수 없었다.
저 유방암 진단받고 치료받는거 따라다니다가 자기도 속이 좀 불편하다고 내시경 한번 해보겠다며 검사를 했는데 위암이
나왔어요. 나는 2긴데, 남편은 3기래요.
이런…
항암치료 받고 수술받은 남편 때문에 보호자 침대에서 쪼그리고 자는 생활 몇일 했더니 몸이 아주 망가졌나봐요. 너무 힘드네요.
한주 쉬고 다음주에 항암치료 할까요?
언제 집에 내려갔다가 또 와요? 수치 괜찮으면 그냥 오늘 치료 받을래요.
집이 지방이라 한주 공치고 갔다 오는게 부담인가 보다. 항암치료를
할 때는 수치가 괜찮아도 주관적인 컨디션이 좋지 않으면 치료기간이 힘들다. 한주 정도는 쉬어도 치료
결과에 지장이 없으니 한주 쉬었으면 좋겠는데 환자는 그럴 여유가 없나보다.
3주가 지나고 그녀가 다시 항암치료를 받으러 왔다. 이번에는 병원 입원복을 입은 남편이 항암주사가 연결된 주사를 폴대에 매달고 진료실에 같이 따라왔다. 우리 환자 처음 항암치료 받을 때 같이 설명을 들으시던 모습이 어렴풋이 기억이 난다. 외래 진료실에 진료를 볼 때는 환자와 집중해서 이야기하고 논의하기 때문에 보호자에 대해서는 별로 주의를 기울이지
않아서 나중에 보면 어떤 환자 보호자셨는지 잘 기억이 안난다.
남편도 항암치료 받고 저도 항암치료 받고 이게 뭐하는 건지 모르겠어요.
뭐하는 거긴요. 잘 치료받고 있는 거지요.
선생님 저도 하루 입원하면 안될까요? 항암제 맞고 남편 간호하는거
힘들어서요. 저도 하루 편하게 자고 쉬었으면 좋겠어요.
환자와 대화를 중단하고 원무과에 전화를 해보지만 이미 1인실도 빈
자리가 없다고 한다.
우리 대화를 지켜보던 남편이
오늘은 내가 보호자 침대에서 잘께. 당신이 내 침대에서 자.
그러세요. 남편이 맞는 항암제보다 우리 환자가 맞는 항암제가 더 쎈거에요. 남편분은 별로 안힘들지도 몰라요.
남편보다 당신 항암치료가 더 힘들거니까 대접받아야 한다는 말에 환자가 씩 웃는다.
환자 마음에 오만가지 상념이 오가고 있을텐데. 그래도 환자니까 대접받아야
한다는 말이 내심 만족스러우셨나 보다. 부부 모두 몸과 마음이 힘들 때다.
그렇게 같이 항암치료를 받는 또 한 커플이 있다.
이들 모두 수술 후 항암치료 중이다.
남편 환자는 기골이 장대하고 잘 생기고 인상도 좋고 훈남형이다. 먹는
항암제를 먹은 후로 10kg 이상 몸무게가 줄었다고 하는데, 내가
보기에는 딱 좋다. 우리 환자는 키도 크고 미인이고 항암치료 후 이제 머리가 삐뚤삐뚤 나기 시작하는데
아주 시크하고 멋진 외모를 가지고 있다. 미남미녀 커플이시다. 그렇지만
그렇게 젊은 부부 둘이 같이 치료를 받으니 집안 꼴도 엉망이고 애들 관리도 엉망이라며 엄마 환자는 우울해 한다.
본인이 먼저 진단받고 남편이 나중에 진단받았다. 그녀도 자기 항암치료 중에 남편 수술 뒷바라지를
다 했다. 명랑하고 씩씩했던 그녀가 시간이 지나가면서 지치고 힘들어 하는게 눈에 보인다. 허셉틴도 맞고 호르몬제도 먹는 엄마 환자는 호르몬제를 복용하는게 항암제보다 훨씬 힘들다고 한다. 가끔 눈물을 보인다.
너무 젊어서 여성호르몬이 많은데 그걸 억지로 억제하니까 더 힘든가봐요.
젊다는 증거라고 생각하세요.
제 몸 어디에 그렇게 여성 호르몬이 숨어 있었던 걸까요? 저 무지하게
터프하고 남성적인데 이럴 때만 꼭 여성적이에요.
그녀가 다시 농담을 시작한다. 우리의 치료가 끝나가니 조금씩 좋아지고
있나 보다. 서로 우울해 하며 힘들어 하던 이들 커플은 억지로 기운을 내서 동남아시아 여행도 다녀오고
서로가 지치지 않기 위해 노력하고 있다. 정신과 면담도 자청해서 받으며 병에 지지 않으려고 최선을 다해
노력하는 커플이다.
개발자 컨퍼런스라고 하면 생각나는 분위기가 무엇인가요? 저는 격식인 것 같습니다. 호텔의 넓은 컨퍼런스홀의 좌석에 앉아서 발표를 열심히 듣는 장면이 떠오릅니다. 쉬는 시간에 친구를 만날 때 이외에는 행사 순서에 맞추어 수동적으로 사람들을 따라 다녔었습니다.
지식을 짧은 시간 내에 집중해서 얻을 수 있다는 점은 좋지만 가끔은 다른 형태의 행사도 있었으면 하는 아쉬운 바람이 있었습니다. 다행히 최근에는 개발자들의 관심사를 나누는 모임들도 종종 개최되는 것 같아 다행인데요. 지난 토요일에 개최된 쿨한 개발자 행사를 표방하는 DevFestX Korea 2012 행사도 그런 행사 중 하나였습니다.
이번 행사는 국내 구글 개발자 커뮤니티들이 함께 준비하고 구글 코리아가 후원하는 형식으로 진행되어 서울 GTUG, 수원 GDG, Golang Korea, Dartlang Korea, App Engine Korea, Android User Group in FB 등 다양한 커뮤니티들이 함께 힘을 모았습니다.
이런 행사가 구성되기 위해서 기본적으로 자신이 가진 지식과 경험을 다른 사람들과 함께 나눌 수 있는 발표자가 있어야 할텐데요. 이번 행사의 발표자들은 모두 자발적인 참가 신청을 통해 선정되었다는 점이 매우 고무적이었습니다. 모바일, 웹&클라우드, 이머징으로 구성된 트랙에 무려 23개의 세션이 포함되면서 안드로이드, 크롬, 앱엔진, Dart, Go 등등 매우 다양한 주제를 다루어 평소에 부족했던 정보를 채우고 새로운 화두도 얻을 수 있었습니다.
쉬는 시간과 행사 후반부에는 발표자와 참여자가 함께 대화를 나눌 수 있도록 많은 장치들이 배치되었습니다. 시간의 부족으로 미처 하지 못했던 이야기들도 나눌 수 있었고요. 비슷한 주제에 대해 관심을 가진 사람들끼리 토론을 나눌 수도 있었습니다. 다양한 분야의 사람들이 모였기 때문에 발표자나 참여자가 새로운 가능성에 대해 이야기하는 경우도 있었습니다. 안드로이드의 접근성 문제에 대한 사회적 기업의 가능성에 대한 이야기를 나누기도 했고, 오픈 소스에 대해 어떻게 기여를 할지에 대한 계획을 나누기도 했습니다. 아두이노와 예술을 어떻게 결합할 것인지에 대해 이야기를 나누는 분들도 있었습니다. 이렇게 함께 모인 개발자들은 서로 더 많은 이야기를 하며 비전을 공유할 수 있었습니다.
학교를 다니거나 회사 생활을 하게 되면 매일 시키는 일만 하거나 과제를 하며 시간을 보내는 경우가 많은데 저는 이번 DevFestX Korea 2012 행사를 통해 일상에서 벗어나 더 큰 세상을 보고 새로운 열정을 느끼고 공유할 수 있었습니다. 제게 이번 행사는 즐겁고 쿨한 축제였을 뿐만 아니라 개발자로서 조금 더 나은 미래를 생각하며 진지하게 참여할 수 있었던 축제였습니다. 앞으로도 이렇게 열정을 공유할 수 있는 기회가 계속해서 자주 있었으면 좋겠네요~!
사전에 따르면, 1879년의 독일-오스트리아 동맹 Austro-German Alliance 이란 다음과 같다.
독일과 오스트리아간에 체결된 방어동맹. 베를린회의 후 러시아에는 반독일적 풍조가 증대했으므로 O.E.L. 비스마르크는 러시아에 대비하는 동시에 오스트리아가 러시아 혹은 프랑스와 협정을 맺을 위험을 방지하기 위해 1879년 10월 7일 빈에서 동맹조약을 체결하였다. 주요내용은 ① 체결국의 한쪽이 러시아의 공격을 받을 경우 양국은 전병력으로 상호지원할 것 ② 러시아 이외의 제3국(프랑스)으로부터 공격을 받았을 경우 다른 한쪽은 호의적 중립을 지킬 것을 약속하는 것이었다. 조약기간이 5년인 이 비밀조약은 1887년 공표되어 제1차세계대전 때까지 계속되었다.
<제1차세계대전의 기원>에서 요하임 르마크는 비스마르크의 의도에 대해서 다음과 같이 설명한다.
독일-오스트리아 동맹으로, 독일의 운명을 곤경에 있던 오스트리아의 운명에 연결시키게 되었다는 비판이 제기되기도 했다. 하지만, 이것은 크게 문제가 되지 않았다. 왜냐하면, 동맹으로 독일이 오스트리아에게 묶인 것이 아니라, 오스트리아가 독일에게 묶였기 때문이었다. 비스마르크는 "모든 동맹체에는 말의 역할을 하는 국가와 기사의 역할을 하는 국가가 있다"고 주장한 바 있었다. 이 동맹에서, 기사 역할을 한 것은 바로 독일이었다는 것이다. 비스마르크는 빈 주재 독일 대사에게 보낸 훈령에서 다음과 같이 강조했다 : "발칸 지역에서 자신의 야망을 달성하기 위해서, 오스트리아가 독일의 군사력을 이용하려 할지도 모른다. 우리는 이같은 오스트리아의 구상을 절대로 고무시켜서는 안된다."
이 동맹이 "방어적" 성격을 가지고 있었다는 점이 중요했다. 만일 오스트리아가 러시아 공격의 희생양이 된다면, 독일은 오스트리아를 자동적으로 지원할 것이었다. 하지만, 비스마르크에 따르면, "독일은 러시아를 공격하지 않을 것이고, 공격할 의사도 없다." 그리고 "만약 오스트리아가 러시아를 공격한다면, 독-오 동맹은 전혀 효력을 발휘할 수 없다." "독일이 발칸문제로 절대로 전쟁을 할 수 없다."는 것이었다.
독-오 동맹 때문에, 러시아가 프랑스 등의 서방 국가와 동맹을 체결할 가능성이 있다는 비판에 대해서도 비스마르크는 다음과 같이 반박했다. 비스마르크는 "러시아는 서방세계의 국가들과 결코 제휴할 수 없고 또한 제휴하지도 않을 것이다."라고 굳게 믿었다는 것이다. 이념적으로나, 정치적으로나 짜르의 국가와 영국,프랑스 사이에는 큰 차이가 있었다. 따라서 비스마르크는 "독일과 오스트리아 간의 견고한 결속 때문에 외교적 고립에 직면할 경우, 러시아는 독일,오스트리아에 대한 분노를 버리고, 현실과 타협할 것"이라고 계산했다는 것이다.
이와 같은 비스마르크의 계산은 적중했고, 1881년 독일,오스트리아,러시아간의 3제동맹이 부활된 것은 바로 이같은 상황에서 였다.
A team from Imperial College found that in 2009-10, nearly 20,000 adults were coded as having attended paediatric outpatient services, and 3,000 patients under 19 were apparently treated in geriatric clinics. Even more striking, between 15,000 and 20,000 men have been admitted to obstetric wards each year since 2003, and almost 10,000 to gynaecology wards.
It's hard to put your faith in analysis, visualization, policy, and anything else that comes out of data with reports like these. With human error being a known issue, we have to find better ways of inputting and double-checking data. Unfortunate mistakes at the outset only lead to bigger problems down the line.
책내용 중에서, 자본주의가 붕괴한 뒤, 해방적인 사회주의가 반드시 출현할 것이라는 마르크스의 유령을 비판하면서, 자본주의의 몰락 이후 훨씬 더 나쁜 체제가 등장할 수 있다고 지적하는 것이 흥미롭다. 가령, 1848년 혁명들 이후의 보나파르트 황제 복고, 1932년 독일 히틀러 세력의 집권과 같은 역사적인 퇴행 말이다. 뿐만아니라, 퇴행적 좌파의 출현도 우려스러운 일이라고 한다.
거의 대부분의 사람들은 컴퓨터에서 문서를 작성할 때 마이크로소프트 워드와 같은 프로그램을 쓸 것이다. 워드 같은 프로그램을 아시다시피 위지위그(WYSIWYG, What You See Is What You Get) 편집기라 한다. 실제 종이로 출력될 문서와 같은 (아니면 거의 흡사한) 형태를 직접 보면서 편집하는 툴이다. 초등학교 시절이었던 1989년, 금성사(…)의 장원이라는 워드프로세서가 있었는데 그건 위지위그 방식이 아니었다. 게다가 텍스트 화면에서 편집하는 프로그램이었다. 그러다가 1991년 정도에 접한 새로운 워드프로세서가 있었는데 바로 아래아 한글.
아래아 한글은 그래픽으로 작업을 해서 거기서부터 주는 충격이 대단했다. 그리고 위지위그 편집이 가능했다. 한글에서 편집한 문서를 엄청난 소음과 함께 출력되던 도트 프린터로 출력해서 본 기억이 아직도 난다.
2. 위지위그 편집기
위지위그 에디터와 대비되는 대표적인 문서 편집 도구로 LaTeX (레이텍)이 있다. LaTeX은 Knuth 선생이 만든 TeX라는 조판 언어에 기반한다. 이걸 전산학계에서 매우 유명하신 Lamport 선생이 개선한 것이다. 전산학자가 만든 문서 편집 프로그램이니 지극히 프로그래밍적으로 접근한다.
LaTeX는 위지위그와는 판이하게 다르게 마치 HTML을 날로 코딩하듯이 특수 조판 기호를 이용해 소스 코드를 작성한다. 그리고 이 소스 파일을 ‘컴파일’한다. 맞다. 코딩할 때 그 컴파일 바로 그것이다. 그러면 이 문서 소스 코드는 DVI, PS(Post Script), PDF 포맷으로 출력된다. 소스 코드에 오류가 있으면 컴파일 에러도 뜬다. 컴파일 경고도 있다. 리눅스에서 작업한다면 Makefile로 컴파일할 수 있다.
\LaTeX{} is a document preparation system for the \TeX{}
typesetting program. ... 생략 .... \LaTeXe.
% This is a comment; it will not be shown in the final output.
% The following shows a little of the typesetting power of LaTeX:
\begin{align}
E &= mc^2 \\
m &= \frac{m_0}{\sqrt{1-\frac{v^2}{c^2}}}
\end{align}
\end{document}
HTML 날 코딩 해보신 분이라면 그렇게 이상하게 보이지 않을 것이다. \usepackage는 마치 C/C++의 #include, Python의 import와 흡사하다. 키워드/매크로를 사용하고 있으며 무엇보다 복잡한 수식을 명령어로 섞어 표기하는 것이 가장 큰 특징이자 장점이다. 위 소스 코드를 컴파일하면 다음의 출력물이 나온다.
처음에는 도대체 LaTeX 이거 뭔가 욕하다가 컴파일-출력물 보기에 중독 되기도 한다.
Latex이 위지위그에 비해 가지는 장점이 여럿 있다.
많은 장 수가 있는 문서 편집에 강하다. 소스 파일은 그냥 텍스트 파일이므로 편집에는 시스템 부담이 없다. 특히 100장이 넘는 큰 문서 작업 시 여러 소스 파일에서 작업한 뒤 하나의 PDF로 컴파일 할 수 있다. 프로그래밍과 너무 닮았다.
상호참조가 많은 경우, 예를 들어, 그림/표/수식 번호를 자주 참조해야 할 때, 워드 같은 프로그램보다 상당히 편리하다. (워드에서도 직접 그림 번호를 치지 않고 상호참조를 쓸 수는 있으나 상당히 불편하다.) 참고문헌 역시 Bibtex라는 프로그램과 함께 쓰면 편리하게 작업할 수 있다.
수식 편집이 강력하다. TeX 자체가 Knuth가 자신의 책의 수식이 아름답게 출판되지 못해 만든 프로그램이니 어찌 보면 당연한 얘기. 강력할 뿐만 아니라 아름답게 출력된다. 수식 외에도 문서의 세밀한 부분을 조절할 수 있다. 예를 들어, 문단 사이의 간격을 정밀하게 조절할 수 있다.
여러 사람과 공동 작업이 편리하다. 텍스트 파일에서 작업이 이루어지므로 개발 협업에서 쓰는 SVN/GIT을 그대로 써서 협업할 수 있다. 역시 텍스트 파일에서 이루어지니 매크로/스크립트의 사용이 쉽다.
이러한 이유로 LaTeX은 특히 논문을 써야 하는 대학원/교수 사이에서 많이 사용된다. 수식이 많은 물리/수학/통계 분야는 당연하고 솔직히 수식도 별로 없는 전통적인 전산학 분야에서도 LaTeX은 논문 편집이 표준이다. 물론 전산학에서도 수식이 많이 나오는 머신 러닝 쪽은 거의 필수이지만. 그런데 다른 전공은 LaTeX을 안 쓰는 경우도 많다. 생물학만 하더라도 (수식이 별로 없으니) 거의 쓰지 않는다고 한다.
하지만 LaTeX도 불편한 점도 많다. 마치 vim과 워드와 같은 차이라고 볼 수 있다. 워드는 전혀 사용법을 몰라도 시간이 지나면 터득이 되지만 vim은 공부를 하지 않으면 아예 전혀 사용할 수도 없다. 누군가 그러지 않았는가. 랜덤 문자열을 얻으려면 vim이나 emacs를 초보자에게 주고 종료시키도록 하면 된다고. LaTeX도 그러하다. 초기 진입 장벽이 상당히 있다.
한편, 위에서 장점이라고 언급한 것도 양날의 검처럼 단점이 동시에 있다.
큰 문서 편집에 강점은 있으나 100장이 넘는 대량의 문서를 컴파일하면 부담이 심하다. 특히 LaTeX 컴파일러는 incremetal하게 되지 않아 글자 하나만 고쳐도 전체 문서를 몽땅 재컴파일 한다. Rebuild All! 그래서 현재 편집하는 장만 추려서 작업할 수밖에 없다. 10장 정도의 논문 역시 막판 장 수를 맞추기 위해 세밀한 편집을 할 때는 매우 빈번하게 컴파일과 미리 보기를 해야 하는데 너무너무 피곤하고 지루한 과정이다.
상호참조는 LaTeX에서 각 객체에 label을 주고 그걸 \ref{객체이름}으로 쓴다. 편리하다. 10여장의 논문은 큰 불편함이 없지만 100장이 넘는 박사 논문 같은 경우 수 많은 그림/도표/수식을 체계적으로 정리하기가 간단하지는 않다. 다행히 대부분의 전용 LaTeX 편집기는 Visual Studio 같은 자동완성 기능을 제공한다.
수식 편집이 강력하나 초보자는 명령어를 다 못 외우니 삽질이 심하다. 그래서 WYSIWIG로 수식을 입력하면 LaTeX 코드로 바꿔주는 툴도 있다.
LaTeX로 정밀한 문서 편집이 가능은 하나 이걸 하기가 쉽지 않다. 예를 들어, 도표의 한 셀의 테두리 모양을 바꾸고 싶다면 워드에서는 클릭-우클릭-세팅 설정으로 된다. 그러나 LaTeX에서 이걸 하려면 너무 괴롭다. 마우스로 한 방에 될 것을 검색을 해서 다시 코드를 고쳐야 하는 수고를 해야 한다.
3. LaTeX와 위지위그의 편리함을 합친다면?
이렇게 LaTeX와 위지위그 에디터는 그 장단점이 너무나 뚜렷하다. 분명 어느 한 쪽이 완전히 우세하다고 말 할 수 없다. 그렇다면 자연스럽게 이 두 방식의 절충점을 찾고 싶을 것이다.
아직까지 아래아 한글 수식 편집기의 명령어가 외워지고 있다니. 수식이 이게 맞던가..
아래아 한글의 수식 편집기는 위 그림처럼 LaTeX를 연상케 하는 코드로 수식을 편집할 수 있게 한다. 학부 주전공은 물리/역학 수업이 많아서 수식 편집을 많이 했다. 나는 여전히 15년 전에 쓴 아래아 한글의 수식 편집이 손에 익다. 마우스를 손에 거의 댈 필요가 없다. 워드 2007/2010의 수식은 위지위그 방식으로 편리는 하지만 지나치게 마우스 클릭을 많이 해야 해서 대량의 수식이라면 너무 피로하다. 하지만 아래아 한글은 입력 방식은 훌륭하나 정작 출력/인쇄 과정에서 문제를 많이 일으켰던 기억이 난다.
LaTeX의 매우 불편한 재컴파일-미리보기 과정을 진정 위지위그화한 편집기도 있다. 이름이 굉장히 기괴한데 BaKoMa TeX라는 상용 툴이 있다. 러시아계 사람 같은 1인 개발자가 10년 넘게 혼자 만들어서 파는 프로그램이다. 홈페이지 디자인도 너무나 촌스러워 신뢰가 안 가는데 써보면 충격과 공포 그 자체다. 정말 레이텍을 상당한 수준의 위지위그로 만들었다. 글씨를 치면 바로 incremental 컴파일을 해서 진짜 결과물을 보여준다.
주 편집 창에서 편집을 하면 왼쪽 하단에 있는 LaTeX 소스 파일도 알맞게 코드가 생성된다. 반대로 소스 코드를 직접 고쳐도 명시적인 컴파일 없이 즉각 화면에 반영된다. 평가판으로 써보고 너무 좋아서 지금은 구입해서 사용 중이다. 안타깝게도 자잘한 버그가 많아서 불편한 점이 꽤 있으나 문제점을 메일로 보내면 거의 개발자가 24시간 내에 직접 고쳐주고 진단해주기도 한다(...) 진정 장인의 숨결이 느껴지는 소프트웨어이다. 그러나 이런 노력에도 불구 원초적으로 LaTeX가 가지는 한계점으로 정말 워드처럼 편리하게 쓰는 느낌은 들지 않는다. 복잡한 논문을 바로 여기서 작업하기에는 쉽지 않을 수 있다. 그 보다는 이미 작성된 레이텍 파일을 후편집할 때 매우 편리하다. 하지만 이러한 장애를 극복하고 이 정도 수준의 소프트웨어를 만든 것도 대단하다. LaTeX으로 논문 많이 쓰는 사람에겐 무조건 강력 추천한다.
LaTeX의 종결자는 프리젠테이션 파일과 그래프도 LaTeX으로 만드는 것이라고 한다. 각종 실험 그래프도 스크립트를 이용해 LaTeX 혹은 다른 벡터 그래픽 언어로 그릴 수 있다. 나는 그렇게 대량의 데이터를 수집하는 실험을 많이 하지 않아 엑셀 노가다로 해결이 되지만, 스크립트로 결과를 파싱해 프로그래밍적으로 그래프를 그린 뒤 PDF로 뽑아서 보는 친구도 있다. 자명하게 이에 대응되는 위지위그 방식은 파워포인트/엑셀일 것이다. 파워포인트는 대부분의 경우 편리하고 직관적이나 위지위그 방식이 너무나 불편할 때가 종종 있다.
사실.. 이 글을 쓰게 된 것도 지금 발표용 슬라이드를 만들고 있는데, 위 그림처럼 복잡한 에니메이션을 넣다가 사람 환장할 것 같아 충동적으로 쓰고 있다. 간단한 애니메이션은 우아하게 클릭 클릭으로 해결된다. 그런데 개체가 날라 다니고 텍스트 내용이 바뀌고 등등의 복잡한 애니메이션을 클릭으로 하기란 너무나 고통스럽다. 고치기도 너무 어렵고 몇 픽셀 차이로 어긋나는 것도 잡기가 너무 어렵다. 이럴 때 이런 에니메이션을 스크립트로 처리할 수 있으면 얼마나 좋을까?
그런데 이론적으로는 가능하다. 거의 10년 전인, 2003 년, 회사에서 해야 했던 일이 딱 파워포인트 같은 편집 툴을 만드는 것. 핵심은 undo/redo가 지원되는 C++ 컴포넌트 아키텍처 + GUI 인터페이스를 만드는 것. 처음에는 갈피를 못 잡다가 파워포인트를 열심히 파고 드니 파워포인트의 각 개체가 프로그래밍적으로 접근이 가능함을 알았다. 우리가 눈에 보는 것은 마우스와 키보드의 위지위그지만 실제 내부는 프로그래밍적으로 문서를 만들고 개체를 넣고 수정하고 그런 것이 되는 것이다. 컴포넌트를 조작하는 엔진과 그 엔진에게 명령을 전달하는 GUI 껍데기의 확실한 구분이었다. 이런 접근 방식을 보자마자 어려워 보이던 문제가 쉽게 풀릴 수 있었다.
위 그림을 보면 각 개체마다 이름이 다 있다. 그러니 얼마든지 애니메이션을 프로그래밍 형식으로 제어할 수 있을 것이다. 다만 마이크로소프트가 이런 인터페이스를 노출 안 시킬 뿐. 마찬가지로 워드도 복잡하고 큰 문서를 작성하면 비슷한 난관에 봉착한다. 역시 이럴 때 LaTeX 처럼 편집할 수 있는 모드도 있으면 얼마나 좋을까?
4. 무한한 시간과 돈이 있다면
나는 Visual C++를 15년 넘게 쓰고 있는 사람이다. 그런데 리눅스도 많이 쓸 수밖에 없어 vim + Makefile로도 작업을 5-6년간 꽤 했다. 이 판이하게 다른 개발 환경을 보고 있자면 (물론 리눅스에서 이클립스가 있긴 하지만) 너무나 위지위그와 LaTeX의 차이점이 떠오른다. (아 그렇다고 Visual C++을 클릭클릭하는 RAD 툴로 생각하면 큰 오산!) 여기서 어느 방법이 좋다/나쁘다를 논하고 싶지는 않다. 할 말이 너무 많아서…
그러나 하나 확실한 것은 위에서 얘기한 LaTeX와 위지위그의 차이처럼 양 개발 방법론도 매우 뚜렷한 장단점이 있고 어느 한 쪽이 완전히 다른 한 쪽을 제압할 수 있는 것이 아니다. 각 방법론의 장점을 모은다면 분명 나은 개발 환경을 만들 수 있을 것이다. 그런데 각 진영의 사람은 자신의 방식에만 너무 매몰되어있는지 서로의 장점을 잘 모은 도구가 나오지 않고 있다. 너무 아쉬울 뿐이다.
정말 나에게 무한한 시간과 돈이 있다면 소개한 BaKoMa TeX의 1인 개발자처럼 혼자서 Visual Studio + Makefile의 장점을 합친 개발 환경이나 만들고 싶다.
p.s. 윈도우에서의 추천 LaTeX 환경: MiKTeX (윈도우 용 LaTeX 배포) + TeXnicCenter (GUI 편집기) + Sumatra PDF (PDF 뷰어). (PDF 뷰어로 일반 Acrobat을 쓰면 매우 불편한 점이 있다. 편집 중인 PDF가 아크로뱃이 열고 있는 도중에 재컴파일을 하면 아크로뱃은 다시 로딩을 하지 못하거나 컴파일 자체가 잠겨있는 파일이라고 안 된다. 반면, Sumatra PDF 뷰어는 공유 모드로 파일을 읽어서 자동 갱신이 되어 LaTeX 작업에 안성맞춤.)
한 줄로 요약하자면 하둡의 MapReduce 에서는 중간에 I/O가 참 많이 발생한다... 정도가 되겠다.
글의 마지막에 보면 몇 가지 질문을 던지고 있다.
우선 하둡은 map task 실행 시 가급적 해당 task가 처리할 데이터가 있는 노드에서 실행되도록 job tracker가 task를 할당하고 있는데 글쓴이가 실제 실험을 해보니 원격 노드에서 실행을 하더라도 그에 따른 부하가 전체 I/O에서 그리 크지 않은 것 같다고 했다.
이건 테스트를 위해 사용한 예제가 데이터 정렬이었기 때문에 그렇다. 데이터 정렬은 그 특성상 Map 에서 처리하는 데이터와 Reducer로 넘어가는 데이터 양이 동일한데, 원래 MapReduce 모델은 maper에서 로컬 데이터를 처리해서 reducer로 넘어갈 때 데이터 양을 줄일 수 있는 로직이 큰 성능 효과를 발휘하는 모델이다.
이게 만약 정렬이 아니라 combiner가 적용된 word counter 같은 예제였다면 결과는 크게 다를 것이다.
또 map task는 결과를 로컬 디스크에 저장하고 reducer가 web proxy를 이용해서 각 map task의 결과물을 가져가는 방식인데, 글쓴이는 map 결과를 HDFS에 저장하는 것이 좀 더 단순해서 reducer 최적화에 유리하지 않을까라는 질문을 하고 있다.
이에 대한 내 생각은 다음과 같다.
첫 째, HDFS에 저장하게 되면 복사본을 추가로 저장하는 부담이 생긴다. HDFS는 기본 설정이 3개의 복사본을 저장하게 되어 있기 때문에 각 map task 결과물을 HDFS에 저장하려면 2번의 추가적인 I/O가 발생한다. 게다가 이 추가적인 쓰기 작업은 모두 원격 I/O이다.
둘 째, HDFS에 저장하게 되면 map task는 다른 노드의 장애에 영향을 받게 된다. map task 결과를 로컬에 저장하게 되면 해당 노드의 장애에만 영향을 받게 되지만 HDFS에 저장하면 data node 의 장애도 수행 시간이나 결과에 영향을 줄 수 있다. 게다가 map task가 수행되는 노드에 장애가 나거나 반대로 저장하는 data node에 장애가 나거나 혹은 둘 다 문제가 생겼을 때 등 장애 처리를 위해 고려해야 할 경우의 수가 더 많아져서 장애 처리 로직이 복잡해 진다. (그렇지 않아도 map 결과를 저장하는 로직은 하둡 전체 소스를 통털어 가장 복잡한 로직이다.)
그 외에 네트워크 대역폭이 10GB 정도로 크면 지역성이 크게 의미없지 않을까? 라는 질문도 있다. 즉, 이 정도 대역폭이면 디스크I/O나 네트워크 I/O나 성능이 비슷하지 않겠냐는 뜻 같다. 하지만 분산 시스템에서 네트워크는 일종의 공공재이기 때문에 다른 작업에 대한 영향력을 생각해야 한다. 따라서 단일 작업에서의 성능은 차이가 없더라도 여러 job을 한꺼번에 돌리는 상황에서는 locality가 여전히 중요한 최적화 요소일 것이다.
암튼 뭐 내 생각은 이렇고 다음 번에 자신의 질문에 대한 내용으로 글을 쓰겠다고 하니 어떤 내용일지 한번 봐야 겠다.
건강보험심사평가원 탐방기 1. 서론 우리나라 의료시스템을 이해하기 위해서 중요한 기관 중 하나는 건강보험심사평가원이다. 심평원은 2000년7월에 보험자와 심사기구를 분리 해야 한다는 명목아래 건강보험심사평가원 와 국민건강보험공단으로 나누어졌다. 의료기관에서 진료를 받았을 때 의료기관은 총 진료비중 일부를 환자에게 받고, 나머지는 건강보험심사평가원에 청구 한다. 이때 건강보험심사평가원은 청구된 진료비에 대한 심사와 진료가 적정하게 이루어졌는지에 대한...
어린아이가 우물에 빠진다. 우리는 그 아이에 대해서 측은한 마음을 갖는다. 동시에 우리는 그 아이에 대해서 차마 안 할 수 없는 마음, 즉 반드시 해야만 하는 마음을 갖는다. 그를 구해주고 도와주어야 한다. 이 측은한 감정 혹은 반드시 해야만 하는 마음을 어떻게 규정할 수 있는가? 그것은 도덕적 감정인가? 그것은 도덕적 마음인가? 이 감정과 마음의 원천, 근거가 무엇인가? 그것은 칸트가 이야기한 것처럼 인간성 혹은 생명성에 대한 존중, 존경 때문인가? 따라서 우리는 측은한 마음을 단서로 삼아 그 배후에 있는 거대한 원리, 인간성과 생명성에 대한 존경과 외경을 추론할 수 있고, 그것을 배워 내 몸에 완전히 익혀야 한다. .......
Werkzeug은 프레임워크와 무관한(framework-agnostic) WSGI 테스팅 도구를 제공한다. Werkzeug을 쓰지 않더라도, Python으로 웹 프레임워크를 만든다면 이걸 이용해서 쉽게 테스트해볼 수 있다. WSGI 환경 변수를 테스트 용도로 만들어주는 도구를 따로 만들어야 하나 고민하고 있었는데 이걸로 해결.
최근 글들을 잠깐 짬을 내어 읽어 보니 내가 주석을 과용하고 있는 게 아닌가 하는 생각이 든다. 주석이라 함은 본디 본 글에 속하지는 않으나 흥미로울 내용을 문맥에서 뜯어 내서 본래의 문맥을 훼손하지 않고 새로운 문맥을 주기 위한 장치이다. 그러나 그렇게 뜯어낸 문맥이 본래 문맥보다 더 커지면 문제가 크다. 나의 경우 괄호로 묶을 곁다리 수준의 내용이 두 문장을 넘으면 주석으로 옮기는 현상이 자주 일어나는데, 제대로 하려면 그러한 곁다리 내용을 어떻게 본래 문맥에 녹여낼지를 고민해야 하는 게 맞는 듯 하다. 게으르니까 생각의 흐름을 그냥 흘려 보내는 셈이다. 반성하자.
The unassuming little Descriptive Camera made me rethink data. This project by Matt Richardson was on display at the ITP Spring Show. The basic premise is that you take a photo and the camera spits out a textual description of what it sees. The results are remarkably accurate, detailed, and humorous.
Here's what my photo said:
A woman wearing a seriously awesome jacket that is printed with yellow, blue, and grey circles looks at her ipad rather than making eye contact with Matt Richardson.
I mean, my jacket *IS* seriously awesome! So it not only described what it saw, but it also has great fashion sense. What a clever programmer you may be thinking.
Ah, but it's all a ruse. Albeit, a very novel and sly ruse. Matt described being underwhelmed by the EXIF data provided by digital cameras which provides you with things like date, time, camera model, and sometimes geo-spatial info. He wanted to see a world where cameras actually told you about the contents of the photo. Undeterred by the fact that this type of technology isn't feasible or practical right now, Matt decided to take a more human approach. He uses Amazon's Mechanical Turk and alternatively, instant messages to his friends, to subvert the computational task of providing a textual description of the photo.
So back to how this made me rethink data. It struck me that sometimes it's not what's immediately in front of you. Sometimes it's the shadow of the thing that's important; sometimes it's what envelopes it, or connects it to its surroundings, or maybe even a subjective description of what it is. Sometimes it's not a jacket... it's a seriously awesome jacket.
Stephan T. Lavavej, aka STL, is back on C9! This time, STL will take us on a journey of discovery within the exciting world of Core C++. We know lots of folks are either coming back to C++, coming to C++, or have never left C++. This lecture series, in n parts, is for all of you! Only STL can make that work (novice, intermediate, and advanced all bundled together and presented in a way only STL can do.) Thank you, STL. We're so delighted to have you back!In part 1, STL focuses on Name Lookup, which is a surprisingly complex process.Remember Herb Sutter's great GotW post (#30, to be precise) on Name Lookup? Here's the problem from that post, to refresh your memory (Thanks to Herb for providing information like this on GotW!):In the following code, which functions are called? Why? Analyze the implications?
namespace A {
struct X;
struct Y;
void f( int );
void g( X );
}
namespace B {
void f( int i ) {
f( i ); // which f()?
}
void g( A::X x ) {
g( x ); // which g()?
}
void h( A::Y y ) {
h( y ); // which h()?
}
}
We recommend you watch this entire episode before playing around with Herb's sample above (and don't read the GotW answer, either! That's cheating. Learn from STL. He's an outstanding teacher, as you know.) Please supply feedback on this thread, especially as it relates to what you'd like STL to focus on in subsequent episodes. For part 2, STL will focus on Template Argument Deduction. Tune in. Enjoy. Learn.
음식전쟁 문화전쟁 - 주영하 지음/사계절출판사
문화인류학적인 시각에서 음식의 문화적, 사회적 의미를 분석했다는 책으로 도서관에서 충동 대여해서 읽어보았습니다. 먹거리 관련 책으로 잘 알려진 주영하씨의 책이더군요. 저자의 책은 아직 <차폰 잔폰 짬뽕>과.... 글 전체보기
As previously anticipated, Google introduced Knowledge Graph, a new way to handle queries that replaces keywords with objects. It's like replacing a dictionary with an encyclopedia.
"The Knowledge Graph enables you to search for things, people or places that Google knows about—landmarks, celebrities, cities, sports teams, buildings, geographical features, movies, celestial objects, works of art and more—and instantly get information that's relevant to your query. This is a critical first step towards building the next generation of search, which taps into the collective intelligence of the web and understands the world a bit more like people do," explains Google.
For now, you'll only notice a new info pane in the right sidebar that shows more information about your query. Google's graph has 500 million objects and 3.5 billion facts, so you'll see the new section quite often. Google shows a small thumbnail, a snippet from a Wikipedia article, a few relevant facts and some related queries. It's just like a Wikipedia infobox automatically generated using data from the Web and that's smart enough to only show important facts and hide the things people won't need.
The new info panes will also help users disambiguate queries just like Wikipedia's disambiguation pages help users find the right articles.
Wikipedia's internal links help you find other interesting articles. Google also adds links to all the other objects from the graph.
Some may say that Google borrowed too many ideas from Wikipedia, but that's one step that could help search engines evolve. Understanding the relation between entities and learning their attributes allows Google to answer more complicated questions and get better search results. As Mashable says, "the transition from a word-based index to this knowledge graph is a fundamental shift that will radically increase power and complexity."
Google "begun to gradually roll out this view of the Knowledge Graph to U.S. English users. It's also going to be available on smartphones and tablets". If you don't see the new features yet, check back later.
<RT:FM 나는 개발자다> 행사가 5월 10일 저녁 7시 30분에 홍대 CY씨어터에서 있었습니다. 감사하게도, 100명 가까운 분들께서 행사장을 찾아주셨습니다. 저희는 2시부터 행사장에서 준비를 하고 있었습니다. 보통의 강연회는 이렇게 준비 시간이 많이 걸리지 않습니다. 마이크, 연단, PPT 정도만 잘 준비하면 되니까요. 하지만 이번 행사는 조금 욕심을 부렸습니다. 참석하는 분들이..
더스틴 니퍼트는 이미 한국 이름이 새겨진 유니폼을 입고 경기에 나온 적이 있다. '신경식'이라는 이름으로. (사진=두산베어스)
지금도 가끔 TV를 틀면 볼 수 있다. 아마 오랜 시간이 지나 2078년 쯤에도, 야구가 우천으로 취소된 날에는 여전히 TV에서 볼 수 있을지도 모른다. 무한도전 재방송보다도 더 자주 방영된다는 2006년 제1회 월드베이스볼클래식(WBC) 하이라이트 얘기다. 벌써 6년이나 지났지만, 그때 그 경기들이 가져다준 감동은 아직도 생생하다. 그건 야구선수들에게도 마찬가지다.
“아무리 봐도 지겹지가 않네요.” 훈련이 끝난 뒤, 휴게실에서 WBC 하이라이트를 시청하던 퓨처스팀의 한 선수가 말했다. “아마 저런 대표팀을 다시 한번 꾸리기는 어렵지 않을까요? 타자들도 대단하지만, 투수진은 지금 봐도 정말 놀라울 뿐입니다. 저 선수들이 한 팀에 모여서 활약했다는 게 믿어지지 않아요.”
젊은 선수의 흔한 호들갑이 아니다. 실제로 해외파 투수들이 총출동한 초대 WBC 대표팀 마운드는 미국이나 일본과 비교해도 뒤지지 않을 만큼 막강한 위력을 자랑했다. 2005년 뉴욕 메츠 소속으로 절정의 기량을 뽐낸 서재응을 필두로, 콜로라도에서 선발로 뛰던 김병현과 샌디에이고에서 12승을 따내며 재기에 성공한 박찬호가 모두 합류했다. 여기에 일본킬러 구대성, 빅리그 선발투수의 가능성을 보여준 김선우, 신시내티 마이너 소속의 봉중근도 있었다. 이들에 비하면 손민한이나 박명환, 배영수 등 국내무대 에이스들의 이름이 초라해 보일 정도. 하지만 국내 에이스들 역시 전년도 프로야구에서 최고의 성적을 거둔, 전성기를 구가하고 있는 특급 투수들이었다.
2006년 대표팀 주요 투수들의 전년도(2005년) 성적 박찬호: 30경기 12승 8패 평균자책 5.74 김병현: 40경기 5승 12패 평균자책 4.86 서재응: 14경기 8승 2패 평균자책 2.59 김선우: 24경기 6승 3패 평균자책 4.90 – 이상 메이저리그 배영수: 31경기 11승 11패 평균자책 2.86 손민한: 28경기 18승 7패 평균자책 2.46 박명환: 20경기 11승 3패 평균자책 2.96 오승환: 61경기 10승 1패 16세이브 11홀드 평균자책 1.18
서재응이 선발로 나오고 박찬호가 마무리를 하는 비현실적인 투수진을 앞세운 한국은 WBC 첫 대회에서 4강에 오르는 기적을 연출했다. 특히 빅리거들이 즐비한 미국 대표팀을 상대로 7:3으로 완승을 거뒀고, 일본 대표팀과의 세 차례 대결에서도 2승 1패로 우세했다. 대회 7경기에서 6승 1패에 평균자책은 2.00으로 전체 1위. WBC 4강의 위업은 마운드의 높이 덕분에 가능했다고 해도 지나치지 않을 정도였다.
그로부터 3년 뒤인 2009년에는 제2회 WBC가 열렸다. 이때는 해외파 투수들 대신에 국내 무대에서 활약 중인 젊은 에이스들 위주로 대표팀이 구성됐다. 1회 대회에 출전했던 봉중근을 중심으로 류현진, 김광현, 윤석민의 영 에이스 트리오가 가세했고, 여기에 한창 주가를 높이던 장원삼과 일본에서 활약 중인 임창용이 더해졌다. 무엇보다 오승환과 정대현, 이승호, 임태훈, 정현욱, 이재우 등 강력한 구원 투수들이 같은 유니폼을 입고 던졌다. 이름값의 화려함은 1회 대회보다 약간 떨어지지만, 개개인의 능력과 가능성 면에서는 오히려 더 뛰어나다고도 할 수 있는 라인업이었다.
선수들의 국내 성적에서 드러나듯이, 당시 대표팀은 기량이 최절정에 달한 국내 최고 투수들로 구성됐다. 다들 약속이라도 한 듯 대회를 앞둔 시즌에 최고의 성적을 냈다(류현진은 제외). 기대대로 WBC에서도 좋은 결과가 나왔다. 일본과의 결승에서 아깝게 패하긴 했지만 준우승을 거두면서, 2006년 4강보다 한 단계 위의 결실을 맺었다. 팀 평균자책은 3.44로 1회 때보다 다소 높았지만, 예선 일본전에서 대패한 경기만 제외하면 그 외의 경기에서는 철벽 마운드를 자랑했다. ‘다음 대회 때는 충분히 우승까지 가능하다’는 희망 섞인 관측이 여기저기서 쏟아진 것은 당연한 일.
그런데 문제가 생겼다. 2013년 제3회 WBC를 앞둔 올 시즌 현재, 프로야구 에이스급 투수들의 상태가 심상치가 않다. 윤석민과 류현진을 제외하고는 정상적인 활약을 보여주는 선수가 거의 없다. 투수 부문 각종 순위는 외국인 투수들의 이름으로 뒤덮인지 오래다. 자칫하다간 내년 대표팀 마운드 구성에 큰 어려움을 겪을 수도 있는 상황이다. A 방송의 해설위원은 “지금 상황만 놓고 볼 때는 투수가 없는 게 사실”이라며 “지난 두 대회와 비교하면 너무 약한 투수진이 되지 않을까 걱정된다”는 말로 우려를 나타냈다.
이런 문제는 지난 2009년 대표팀에 참가했던 투수들의 현재 상황을 살펴보면 더 분명하게 드러난다. 당시 참가 투수들 중 올 시즌에도 정상급의 활약을 보여주고 있는 선발투수는 윤석민과 류현진 두 명 뿐이다. 투수 3파전을 펼쳐야 할 김광현은 퓨처스리그에서 컨디션을 끌어 올리는 중이다. ‘봉열사’ 봉중근은 토미존 수술에서 회복해서 이제 막 돌아왔다. 손민한은 무대에서 사라졌다. 좌완 선발로 한 축을 맡았던 장원삼도 올해는 부진하다. 불과 3년 사이에, 대표팀 마운드의 주축을 이뤘던 투수들이 한꺼번에 사라진 셈이다.
반면 빈 자리를 대체해야 할 젊은 투수들은 성장 속도가 더디거나, 오히려 기량이 퇴보하는 모습을 보였다. 일례로 한때 큰 기대를 모았던 양현종과 차우찬은 현재 퓨처스리그로 내려가 있는 상태다. 고원준이나 강윤구, 문성현 등 젊은 선발투수들도 기대치에 비해 보여주는 투구내용은 안정감과는 거리가 있다. 이용찬과 윤성환이 시즌 초반 좋은 투구를 보여주고 있지만, 국제경기에서 한 경기를 책임질 수 있는 투수인지는 미지수다. 사실상 국제대회용 마운드의 세대교체에 실패했다고 봐야 하는 상황이다. 지금 현재로서는 그렇다.
원인이 무엇일까. B 방송사의 해설위원은 “리그 전체적으로 선발투수의 수가 모자라고 질적으로 떨어지게 된 것은 사실”이라고 지적했다. “타자들의 기량 발전 속도를 투수들이 따라잡지 못하고 있다. 프로야구가 발전하면서 중간급 선수들의 기량은 어느정도 올라온 반면에, 상위 클래스 선수들의 기량은 답보하는 모습이다. 최근 몇 년 동안 류현진, 윤석민 등 몇몇 타고난 선수들 외에는 상위 클래스로 치고 올라오는 선수도 거의 없었다.”
그런가 하면 C 방송의 해설위원은 “1군에서 한 명의 선발 에이스급을 키워내기가 보통 어려운 일이 아니다”라고 이야기한다. “1이닝을 책임질 투수를 만들기는 상대적으로 쉽다. 빠른 볼과 주무기 하나만 있으면 불펜에서는 당장 어느정도 써먹을 수 있다. 하지만 선발투수로 6회 이상을, 그것도 시즌 내내 책임질 투수는 좀처럼 만들어내기가 어렵다. 순위 싸움이 치열해지면서 젊은 투수에게 선발로 성장할 기회를 주기보다는, 일단 불펜에서 활용하는 쪽을 택하는 경우가 많아졌다. 선발 두 자리는 어차피 외국인 투수로 채우면 되기 때문에 젊은 투수를 굳이 선발로 써야 할 필요성도 크지 않다.”
실제로 선발투수 기근 현상에 비해 불펜 쪽에서는 투수들이 넘쳐난다. 오승환과 정우람, 손승락을 필두로 박희수, 유원상, 노경은, 안지만, 김혁민 등이 맹활약을 펼치는 중이다. 불펜투수 순위는 국내 투수들로, 선발투수 순위는 외국인 투수들로 철저하게 양분됐다. 여기에 다승 부문 1, 2위에 올라있는 니퍼트와 주키치, 탈보트, 나이트를 한국 국적으로 귀화라도 시켜야 하는 게 아닐까 싶을 정도다. B 방송의 해설위원은 “어중간한 투수를 뽑느니 차라리 박찬호나 김병현을 다시 뽑는 게 국제 경험 면에서는 나을 수도 있다”며 안타까워했다. 박찬호와 김병현은 6년전 WBC에 참가했던 멤버들이다. 그때 그 선수들이 지금 뛰는 선수들보다 낫다는 건, 야구의 미래를 봐서는 그다지 바람직한 현상이 아니다.
현재로서는 일단 퓨처스에 내려가 있는 각 팀 에이스급들이 남은 기간 제 기량을 회복하는 게 최상의 시나리오다. 투수 전문가인 D 방송 해설위원은 “아직 시즌 초반인 만큼 컨디션이 올라오는 선수도 있을 것이고, 젊은 투수들 중에 확 튀어나오는 선수도 나올 수 있다. 1군에 복귀한 송은범도 있다”며 “남은 시즌을 기대해봐야 한다”고 했다. 지적대로 김광현, 양현종, 차우찬이 제 모습을 되찾고 송승준과 김선우가 최소 지난해 수준까지만 올라온다면 대표팀 선발투수 구성에는 어느 정도 숨통이 트일 것이다. “불펜이 워낙 강하니까 류현진 윤석민에 한 명 정도만 더해지면 충분히 해볼 만하다고 본다.” D 해설위원의 말이다.
진짜 문제는 그 다음부터다. 확실히 2009년의 대표팀 마운드는 2006년보다는 선발은 약하고 불펜 쪽에 힘이 실려 있었다. 선발 에이스감이 아예 보이질 않는 올해의 상황은, 그런 추세의 연장선상에 놓여 있다. 다소 극단적인 가정이지만, 이런 추세가 계속 이어지면 앞으로 10년쯤 뒤에 열리는 국제대회 때는 투수진 전체가 불펜 요원들로 채워질지도 모를 일이다. 더 늦기 전에, 야구계가 젊은 투수들의 불펜 쏠림과 넘쳐나는 외국인 선발투수 범람에 대해 진지하게 고민해 봐야 할 것 같다.
What is Missing? by Maya Lin seeks to raise awareness about the mass extinction of species. It has a beautiful interface. The world map is black on a sea of black. Your mouse acts as a sort of flashlight layered between land and water, showing you glimpses of familiar coastlines and allowing you to select dots that tell the stories of extinction.
We are experiencing the sixth mass extinction in the planet's history, and the only one to be caused not by a catastrophic event, but by the actions of a single species - mankind. On average, every 20 minutes a distinct living species of plant or animal disappears. At this rate, by some estimates, as much as 30 percent of the world's animals and plants could be on a path to extinction in 100 years.
The site states that the dots on the world map each represent a species, place, or natural phenomenon that has disappeared or significantly diminished. Unfortunately, this is a very vague concept. I chose a dot titled "Earth" that described the abundance of life in a cup of soil. Another dot named "Migration" discussed how the natural phenomenon of migration was disappearing around the world. It seemed so loosely related to extinction that I felt the mission of the piece fell short. You can also view the dots by year, however, I felt it only added to my confusion because it doesn't seem to chronicle actual extinctions.
I typically love Maya Lin's work, so this site was surprisingly disappointing and certainly not her best piece of data visualization (see Vietnam Veterans Memorial).
이 일본인 기자는 프랑스의 대통령 유세 기간 동안, 마린 르펜의 한 유세에 참석했다. 그리고 그는 다음과 같은 오싹한 경험을 했다고 한다.
일본 도쿄- 도쿄 신문 보도
2012년 5월 15일
노무라 기자
지난 2월에, 나는 프랑스 중부의 작은 도시인 샤토루 Châteauroux 에서 열린, 프랑스 극우파 국민전선의 마린 르펜 후보의 유세에 참석했다. 시간이 얼마 흐른 뒤, 나는 유세장의 사람들이 문자그대로 나를 째려보고 있다는 것을 파악했다. 이렇게 나는 순간적으로 내가 직면했던 상황을 알 수 있었던 것이다.
연단에서 마린 르펜은 샤토루 지역에 중국 기업이 진출하는 것이 초래하는 부정적인 영향을 맹렬히 비판했다. 옛 나토군 공군 기지 자리에 중국 기업들이 자리를 잡게 된다는 것이다. 이 중국 기업들은 프랑스인들을 고용할 것이라 했다. 마린 르펜은 이같은 중국 기업 유치로 <메이드 인 프랑스>의 가치가 하락할 것이며, 프랑스의 고용문제 해결에도 도움을 주지 않을 것이라 주장했다.
내가 이 유세의 자세한 내용을 모두 이해하지 못했다고 하더라도, 이 연설은 외국인을 배격하는 제노포비즘을 주장하는 정당의 그것으로는 전혀 이상할 것이 없었다. 문제는, 내가 유세가 열린 강당 안의 유일한 아시아인이었다는 점이었고, 프랑스인들은 중국인과 일본인을 구별하는데 젬병이다. 나는 따라서 부당하게도 유세장의 표적이 되었다.
유세 말미에, 한 남자가 내게 다가왔다. "당신 중국인이냐?"라고 위협적인 태도로 질문했다. 그는 중화인민공화국과 중국 기업에 대해 말하고자 하는 것처럼 보였다. 내가 그에게 나는 일본인이라 대답하자, 그는 믿을 수 없다는 표정을 지으면서 멀어져 갔다.
프랑스 국민전선이 청년,노동자,농촌인구의 불만을 자극하면서 그들을 유혹하고 있고, 아랍계 이민자와 좌파를 공격하면서 인기를 얻고 있다고 한다. 머지 않은 장래에, 국민전선이 일본과 일본인을 공격하게 될 지도 모른다. 물론, 이번에는 그 남자가 헛다리를 짚었지만, 이번에 내가 겪은 경험은 결코 가볍지도 않고, 우스운 것도 아니라 생각한다.
내가 진짜 노무현 존경하는 거 딱 하나는 막판에 정몽준이 내친 거. 수꼴 애들은 무현이가 원래 미친놈이라 그런 거라고 했는데, 그게 아니고 노무현이 진짜 대통령 감이라 그랬던 거라. 무현이는 애당초 정몽준이랑 손 잡는 거 싫어했거든 그 새끼랑 내가 왜 미쳤다고 손 잡냐고 근데도 그놈의 정치 기계공학 박사 새끼들이 죽어도 손 잡아야 된다고 대통령 되려면 어쩔 수 없다고 지랄지랄개지랄 하는 통에 손은 잡았는데 이거 영 씨발 마뜩치 않았던 거라 ㅋㅋㅋㅋ. 대선 전날 밤에 삐친 정몽준이 집에 찾아 간 무현이 표정 봤냐? ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 아 씨발 내가 왜 이 새끼 집까지 찾아 와야돼 이 표정 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 그.......
프랑스의 신임 총리 관련, 한국 외신기사들을 보니, Jean-Marc Ayrault 를 장-마르크 아이로 혹은 장-마르크 애로라 표기하는 경우가 있었다.
모두 틀렸다.
Ayrault는 애로라 표기하는 것이 맞는 것으로 보이지만, 앞에 장-마르크가 붙어서 Jean-Marc Ayrault인 경우, 장마르크 캐로라 발음하는 것이 맞다. 이는 프랑스어의 연음규칙 때문이며, Marc의 c의 [ㅋ] 발음이 애로와 연음되면서, 장-마르크 캐로가 되는 것이다.
따라서 신임 프랑스 총리는 장-마르크 캐로 다!
다만, 장 마르크를 빼고 부르면, 캐로가 아니라, 애로가 된다.
정리하면, 이름을 장-마르크 캐로 혹은 애로라 불러야 된다는 것이다.
보도에 따르면, 프랑스의 애로 총리는 사회당 하원 원내대표 출신으로, 낭트 시장이라 한다. 그는 독어 교사 출신의 친독파라고 한다. 나는 그가 독어 교사였다는 점이 의미심장하다고 본다.
즉, 올랑드 정권의 애로 총리의 주요 국정 목표가 독일과의 협상에 달려있는 유럽 성장 협약의 성사 여부이면서, 교육 개혁이라는 점을, 장-마르크 캐로 총리의 임명을 통해 알 수 있다고 본다.
There are a lot of ways to show distributions, but for the purposes of this tutorial, I'm only going to cover the more traditional plot types like histograms and box plots. Otherwise, we could be here all night. Plus the basic distribution plots aren't exactly well-used as it is.
Before you get into plotting in R though, you should know what I mean by distribution. It's basically the spread of a dataset. For example, the median of a dataset is the half-way point. Half of the values are less than the median, and the other half are greater than. That's only part of the picture.
What happens in between the maximum value and median? Do the values cluster towards the median and quickly increase? Are there are lot of values clustered towards the maximums and minimums with nothing in between? Sometimes the variation in a dataset is a lot more interesting than just mean or median. Distribution plots help you see what's going on.
Want more? Google and Wikipedia are your friend.Anyways, that's enough talking. Let's make some charts.
This old standby was created by statistician John Tukey in the age of graphing with pencil and paper. I wrote a short guide on how to read them a while back, but you basically have the median in the middle, upper and lower quartiles, and upper and lower fences. If there are outliers more or less than 1.5 times the upper or lower quartiles, respectively, they are shown with dots.
The method might be old, but they still work for showing basic distribution. Obviously, because only a handful of values are shown to represent a dataset, you do lose the variation in between the points.
To get started, load the data in R. You'll use state-level crime data from the Chernoff faces tutorial.
# Load crime data
crime <- read.csv("http://datasets.flowingdata.com/crimeRatesByState-formatted.csv")
Remove the District of Columbia from the loaded data. Its city-like makeup tends to throw everything off.
Oh, and you don't need the national averages for this tutorial either.
# Remove national averages
crime.new <- crime.new[crime.new$state != "United States ",]
Now all you have to do to make a box plot for say, robbery rates, is plug the data into boxplot().
# Box plot
boxplot(crime.new$robbery, horizontal=TRUE, main="Robbery Rates in US")
Want to make box plots for every column, excluding the first (since it's non-numeric state names)? That's easy, too. Same function, different argument.
# Box plots for all crime rates
boxplot(crime.new[,-1], horizontal=TRUE, main="Crime Rates in US")
Multiple box plot for comparision.
Histogram
Like I said though, the box plot hides variation in between the values that it does show. A histogram can provide more details. Histograms look like bar charts, but they are not the same. The horizontal axis on a histogram is continuous, whereas bar charts can have space in between categories.
Just like boxplot(), you can plug the data right into the hist() function. The breaks argument indicates how many breaks on the horizontal to use.
# Histogram
hist(crime.new$robbery, breaks=10)
Look, ma! It's not a a bar chart.
Using the hist() function, you have to do a tiny bit more if you want to make multiple histograms in one view. Iterate through each column of the dataframe with a for loop. Call hist() on each iteration.
# Multiple histograms
par(mfrow=c(3, 3))
colnames <- dimnames(crime.new)[[2]]
for (i in 2:8) {
hist(crime[,i], xlim=c(0, 3500), breaks=seq(0, 3500, 100), main=colnames[i], probability=TRUE, col="gray", border="white")
}
Using the same scale for each makes it easy to compare distributions.
Density Plot
For smoother distributions, you can use the density plot. You should have a healthy amount of data to use these or you could end up with a lot of unwanted noise.
To use them in R, it's basically the same as using the hist() function. Iterate through each column, but instead of a histogram, calculate density, create a blank plot, and then draw the shape.
# Density plot
par(mfrow=c(3, 3))
colnames <- dimnames(crime.new)[[2]]
for (i in 2:8) {
d <- density(crime[,i])
plot(d, type="n", main=colnames[i])
polygon(d, col="red", border="gray")
}
Multiple filled density plots.
You can also use histograms and density lines together. Instead of plot(), use hist(), and instead of drawing a filled polygon(), just draw a line.
# Histograms and density lines
par(mfrow=c(3, 3))
colnames <- dimnames(crime.new)[[2]]
for (i in 2:8) {
hist(crime[,i], xlim=c(0, 3500), breaks=seq(0, 3500, 100), main=colnames[i], probability=TRUE, col="gray", border="white")
d <- density(crime[,i])
lines(d, col="red")
}
Histogram and density, reunited, and it feels so good.
Rug
The rug, which simply draws ticks for each value, is another way to show distributions. It usually accompanies another plot though, rather than serve as a standalone. Simply make a plot like you usually would, and then use rug() to draw said rug.
# Density and rug
d <- density(crime$robbery)
plot(d, type="n", main="robbery")
polygon(d, col="lightgray", border="gray")
rug(crime$robbery, col="red")
Using a rug under a density plot.
Violin Plot
The violin plot is like the lovechild between a density plot and a box-and-whisker plot. There's a box-and-whisker in the center, and it's surrounded by a centered density, which lets you see some of the variation.
The bean plot takes it a bit further than the violin plot. It's something of a combination of a box plot, density plot, and a rug in the middle. I've never actually used this one, and I probably never will, but there you go.
If you take away anything from this, it should be that variance within a dataset is worth investigating. Picking out single datapoints or only using medians is the easy thing to do, but it's usually not the most interesting.
위키 백과에 따르면, 콩코르드 광장(프랑스어: Place de la Concorde)은 프랑스 파리의 광장으로 샹젤리제 거리 동쪽에 튈르리 공원과 사이에 위치한다. 면적은 86,400m2(8.64ha)로 파리에서는 가장 넓은 광장이다.
콩코르드 광장의 스트라스부르 상은 보불전쟁이후 알자스와 로렌을 독일에게 빼앗긴 프랑스의 국민적 분노를 상징하는 것이었다. 프랑스의 이같은 정서는 "항상 알자스-로렌을 생각하라. 하지만, 이를 입밖으로 내지 마라!" 라는 구호로 요약되었다.
콩코르드 광장의 스트라스부르 상 Statue de Strasbourg은 프랑스 도시 스트라스부르를 대표하는 조각상이다. 1870년의 보불전쟁 이후, 조각상은 검은천으로 싸여 있었고, 이는 독일제2제국에 의해서 알자스와 로렌이 상실된 역사적 사실을 상기시키기 위한 것이었다. 제1차세계대전 승전 이후, 검은천은 제거되었다.
오슬롭의 아이들 마지막 사진입니다. 사진을 올리다보니 토이 스토리에서 버즈가 툭하면 외치던 대사 To infinity and beyond!! (무한한 공간 저 너머로!!)가 생각나네요... 어때요? 저 간지 좀 나죠? 파워풀!! 파워풀 파워풀! 살랑살랑!~ 나는 가볍게 나비처럼!~ 파워풀 파워풀 파워풀! 착지(?) 준비! 하트 만드는 중 아, 이 사진은 초점만 맞았으면 대박인데... 아쉬운대로 공개! To infinity and..
1883년 9월 25일(2) 신세계의 병원과 전신에서 이어서 씁니다.
웨스턴 유니언 텔레그래프를 나와서 보빙사 일행은 다음 에퀴터블 빌딩을 방문합니다.
이 에퀴터블 빌딩은 정식으로는 에퀴터블 라이프 어슈어런스 소사이어티(the Equitable life a.... 글 전체보기
2008년 4월 11일부터 시행되고 있는 ‘장애인 차별 금지법’ 제12조 (정보 통신, 의사 소통에서의 정당한 편의제공의무)
2009년 5월 22일 공포된 ‘국가 정보화 기본법’ 제32조 (장애인,노인 등의 정보 접근 및 이용 보장)
‘장애인 차별 금지법 시행령’ : 대통령령으로 정한 공공기관은 1년 이내, 즉 2009년 4월 11일 까지, 그 외 대상은 1년에서 5년내, 즉 2013년 4월 11일 까지 단계적으로 웹 접근성을 준수하도록 하고 있으며, 장애인에게 정당한 편의 제공 규정을 위반할 경우 최고 3000만원의 과태료가 부가되고, 행위가 악의적인 경우 3년 이하 징역이나 3000만원 이하의 벌금을 부과할 수 있도록 규정
웹 접근성까지만 언급되어 있지만, 앱도 대응이 필요하지 않을까 생각됩니다. 하지만, 법을 피해가기 위한 슬픈(?) 작업은 안하고 싶네요.
정리… User = 다양한 사람들…
놀라웠습니다. 시각장애인들이 웹서핑을 하고 스마트폰을 사용한다는 것 자체가 놀라웠습니다.
그리고, 내가 그렇게 놀랐다는 것에 또 놀랐습니다.
그들도 나와 같은 정보와 지식에 메마른 지식인이라는 것을 왜 망각했을까요?
UX는 모두 알다시피 User experience 의 약자입니다. 간담회에 참석한 장애인 중 한분이 이런 이야기를 하더군요. “우리 나라에서 말하는 UX에서 User에는 장애인은 포함되지 않는것 같다.”
IT 기업에서 User라고 생각하는 대상은 좋게 말해서 “서비스를 통해 어떤 유/무형의 가치(Contents)를 만들어낼 수 있는 사람”이라고 표현할 수 있을 것 같습니다. 결국, 최소의 비용으로 최대의 이윤을 얻어야하는 기업 입장으로는 선뜻 *돈 안되는* 작업, *돈 안되는* User에게 투자를 결정하기가 힘들겁니다.
이해됩니다.
그렇지만 그 이상 이야기하면 도덕적으로 창피해 질 듯합니다.
접근성(Accessibility)은 장애인을 위한 것이 아니라 사람을 위한 것입니다. 접근성(Accessibility)이라는 단어에 어디에도 장애인이란 말은 없습니다. 일반인이 느끼는 편리함과 장애인이 느끼는 편리함은 결코 배타적이지 않다고 생각합니다. 접근성이 좋아지면 일반인들도 편해집니다. 접근성을 높이면 UX, UI가 더 직관적으로 표현될 수 밖에 없습니다.
CVI(Customer Value Innovation)팀 내 조사/분석파트는 시장동향분석, 고객리서치, 고객데이터 분석 등을 통해 고객 Needs 및 Unmet Needs를 발굴하여 서비스 개선과 활성화를 위해 노력하는 조직입니다.
이번 조사의 목적은 이미 멋진 아이디어와 실력을 가진 개발사 또는 인디 개발자 분들께서 이용자가 원하는 서비스를 만들기 위해
이용자관점에서 생각하고, 이용자 관점에서 고민하는 기회를 가졌으면 하는 바램으로 기획되었습니다.
향 후에도 개발자 입장이 아닌 이용자 입장에서 고민하는 내용으로 많이 찾아 뵙도록 노력하겠습니다
그럼 아래의 2012년 1분기 스마트폰 이용자조사에 대한 리뷰를 시작해 보겠습니다.
2012년 1분기 스마트폰 이용자 조사
▶ 조사제목 : 2012년 1분기 스마트폰 이용자 조사 ▶ 조사대상 : 스마트폰(팟게이트)이용자 총 7,815명 (아이폰 5,175명+안드로이드폰2,027명) 응답 ▶ 조사기간 : 2012년 3월29일 ~ 4월13일 ▶ 신 뢰 도 : 95% 신뢰수준의 오차범위 ± 1.11%
참고) 용어의 정의 : 구글 플레이는 쉬운 이해를 위해 안드로이드 마켓으로 표시하였습니다.(구글플레이=안드로이드마켓)
1. 모바일 어플리케이션! 레드오션에에서 가능성을 찾아라.
아래 결과에 따르면 한달 평균 어플 설치수는 아이폰 6.6개, 안드로이드폰 5.2개로 아이폰이 안드로이드폰 이용자보다 1.4개 높은 설치개수가
나타났고[참조-그래프1], 한달 평균 실제 이용하는 어플 수는 아이폰 13개 안드로이드폰 11개로 2개 차이가 있었는데
달리 말하면 한 달에 출시되는 수 많은 어플 중 실제 스마트폰에 설치되는 어플은 애플 앱스토어에서는 6.6개, 안드로이드 마켓에서는 5.2개 밖에 안 되는 치열한 레드오션 시장이기도 하다.
그러나 유선Web과 같이 1등이 고착화되어 있는 시장과는 달리 앱스토어이든, 안드로이드마켓이든 1등 유지기간이 일주일이 넘기 힘들 정도로
유연함이 있고, 그 유연함에서 오는 기회는 분명 있다. [참조:그래프2]
[그래프1] 한달 평균 설치 어플 수 [그래프2] 한달 평균 실제 이용하는 어플 수
2. 어플 성공을 위해서는 대형마트 시식코너가 되어야 한다.
이용자들이 어플 설치 시 가장 많은 영향을 미치는 요소 3가지를 물어본 결과, 아이폰/안드로이드폰 이용자 모두 “유료/무료”를 고려한다는 항목이
1위를 차지했다. 이용자가 유료 어플에 대한 장벽을 얼마나 높게 생각하는지 알 수 있는 결과다.
이 결과에 따르면 아무리 잘 만든 어플이라도 무조건 돈을 지불해야 사용할 수 있다면 이용자들이 최초 선택에서 아예 배제 될 확률이 높다는 것이다.
엄청난 마케팅 비용을 가지고 있는 대기업 개발사가 아닌 이상 처음부터 유료화로 접근하여 이용자에게 선택 받을 확률을 스스로 낮추는 것 방법보다, 대형 마트의 시식코너와 같이 적절한 양을 선정하여 ‘무료버전’ 또는 ‘어플 내 구입’ 방식을 통한 매출 발생이 바람직할 것으로 보인다. [참조:그래프3~4]
[그래프3] 아이폰 어플 설치 시 영향요인 3가지 [그래프4] 안드로이드폰 어플 설치 시 영향요인 3가지
3. 젊은 스마트폰 이용자를 잡으려면 스크린샷/미리보기에 올인해라.
어플 설치에 영향을 미치는 요소 중 아이폰/안드로이드폰 이용자 모두 연령별로 공통 특성이 나타나는데 연령대가 높을수록 앱설명(아이폰이용자)
/어플설명(안드로이드폰이용자)이 연령대가 낮을수록 스크린샷(아이폰이용자)/미리보기(안드로이드폰이용자)가 어플설치에 큰 영향을 받는다고 답했다.
이 결과에서 높은연령 이용자에게는 쉽고 자세한 어플설명을 제공하고, 젊은 연령층에게는 스크린샷/미리보기를 통해 한정된 스크린샷 갯수에서
어플의 특장점을 어떻게 넣을지 전략이 필요하다. 이 결과를 미루어 볼 때 많은 개발자들이 스크린샷 중에서도 가장 중요한 첫번째 스크린샷을 등록할 때
어플 실행 시 로딩화면을 등록 하는것에 대해서는 큰 고민이 필요한 할 것으로 보인다. [참조:그래프5~6]
[그래프5] 아이폰 어플 설치 시 영향요인 3가지-연령별 [그래프6] 안드로이드폰 어플 설치시 영향요인 3가지-연령별
4. 디테일이 곧 높은랭킹을 보장한다.
이용자들이 어플 설치 시 가장 많이 찾는 메뉴가 애플 앱스토어는 인기25, 안드로이드 마켓은 인기무료 메뉴로 나타났다. 어플 성공을 위해서는 우리가 만든 어플을 어떻게든 인기25, 인기무료메뉴에 상위에 랭크 시켜야 한다. 이유는 상위에 랭크 되면 다시 다운로드가 되고, 다운로드 되면
다시 상위로 올라가는 선 순환이 일어나기 때문이다.
따라서 이용자들은 어떤 내용을 보고 우리 어플을 설치하는지? 이용자들이 보고 있는 접점에서 우리어플이 얼마나 효과적으로 노출되고 있는지?
디테일을 고민해야 한다. 그 디테일이란? [그래프5][그래프6]에서 보듯이 앱스토어에서는 리뷰/스크린샷/별점/앱설명, 안드로이드 마켓에서는
사용후기/어플설명/미리보기/별점/어플이름이 이에 해당할 것이다. [참조:그래프7~8]
[그래프7] 아이폰 어플 설치 시 많이 찾는 메뉴 [그래프8]안드로이드마켓에서 어플설치 시 많이 찾는 메뉴
5. 이용자의 언어로 말하라~ 검색되지 않으면 존재하지 않는다.
이용자들이 어플 설치시 가장 많이 찾는 메뉴에 대해 연령별 분석을 해 본 결과 아이폰/안드로이드폰 모두 낮은 연령층에서는 트랜드를 반영하는 인기메뉴의 선호가 나타나고, 높은 연령일수록 검증된 추천메뉴에 대한 선호가 나타났다.
여기에서 아이폰의 검색 메뉴가 눈에 띄는데
만약 시간이 갈수록 어플 수가 많아진다고 가정 한다면, 내가 필요한 어플을 앱스토어에서 찾는 게 더욱 어려워 질 것이고, 결국 검색의 중요성이
부각될 것이다.
이는 우리의 과거 십수년간 PC Web에서의 이용행태를 보면 알 수 있는데 PC Web의 초창기 때 인터넷 사용방법은 도메인을 외워서 홈페이지에
접근 했었고(URL직접입력), 정보량이 조금 늘었을 때에는 잘 정리된 카테고리 홈페이지 사이트를 이용 했었고(야후), 정보량이 엄청난 현재에는
검색사이트(구글) 이용할 수 밖에 없는 이유와 같다.
따라서 개발자는 어플 등록 시 이용자들이 검색으로 쉽게 찾을 수 있게 이용자의 언어로 어플 이름을 만들고 어플을 등록할 때 입력하는
키워드 또는 태그를 충분히 고려하여 입력해야 한다. [참조:그래프9~10]
[그래프9] 아이폰 어플 설치 시 많이 찾는 메뉴-연령별 [그래프10] 안드로이드마켓에서 어플설치시 많이 찾는 메뉴-연령별
6. 타이밍과 완성도는 고객의 입장에서 생각하라
모든 서비스 담당자는 런칭시점이 다가오면서 항상 같은 고민에 부딪 치는데, 그것은 타이밍과 완성도에 대한 고민이다.
보통 우리가 타이밍과 완성도의 우선순위를 정하는 방법은 진입장벽이 낮으며 아이디어가 핵심인 어플인 경우는 선점의 우위를 점하기 위해 타이밍이 우선이고, 유사 어플이 이미 출시 되었거나 경쟁이 치열한 어플인 경우는 완성도가 우선이다.는 결정이 힘을 받는다.
그럼 무엇이 정답일까? 아래 조사항목에서 확인해 보자
아래 결과에서 보듯이 어플 삭제 후 재 설치경험의 58.6%이다,
58.6%의 수치를 긍정적으로 본다면 약 10개중 6개는 재설치가 가능하고 우리어플도 6개에 해당될 수 있다는 것이고,
58.6%의 수치를 부정적으로 본다면 약 10개중 4개는 재설치는 불가능하고 우리어플은 4개에 해당되고, 순간의 판단 착오로
몇개월의 노력이 날라갈 수도 있다는 것이다.
따라서, 만약 완성되지 않은 채 어플을 출시해야 한다면 사업자의 입장이 아니라 고객의 입장에서 타이밍과 완성도를 충분히 고민해야 한다.[참조:그래프11~12]
[그래프11] 어플삭제 후 재 설치경험 [그래프12] 어플 삭제 후 재설치경험 – OS별
7. 게임은 타겟별 선호가 분명한 장르이므로 타겟별로 전략을 세워야 한다.
국내 이용자들의 선호게임장르를 알아본 결과 전체 선호게임장르는 퍼즐/보드로 나타났고, 성별구분으로는 남성은 RPG/스포츠/디펜스게임, 여성은 퍼즐보드/아케이드/SNG로 그 선호가 분명하게 나타났다.
신규 게임 장르 진출을 고민하는 개발자인 경우 타겟 이용자의 선호 장르를 고려해 접근해야 하낟.[참조:그래프13~16]
[그래프13] 선호게임 장르 [그래프14] 선호게임장르 – OS별
[그래프15] 선호게임 장르 – 성별 [그래프16] 선호게임 장르 – 연령별
7. 어플의 가장 중요한 시점은 출시 후 한 달이다.
실제 이용자 게임을 설치한 후 집중 플레이 시간을 알아 본 결과 일주일 정도 집중적으로 플레이 한다는 이용자가 36.3%로 가장 많았고, 약 84.7%가 한달이내 플레이 한다고 한다. 이는 디바이스별/성별/연령별로 상관없이 공통적으로 나타나는 현상이다.
(단, 게임장르에 따라 SNG 게임 같은 경우는 집중플레이 기간이 2달을 넘게 한다는 내용이 상위에 있음)
게임을 한 달간 집중적으로 플레이 한 후 더 이상 이용하지 않는다는 결론을 봤을 때, 개발사 입장에서는 한달 이내 투입비용을 모두 회수해야 손익분기을 맞출 수 있다는 결론이 나온다. 달리 말하면 그 만큼 모바일 게임이 트랜드에 민감하고 수명이 짧기 때문에 앞선 기획을 해야하며
적절한 투입자원 고려가 게임 어플 수익창출의 큰 변수가 된다는 것을 알 수 있다.
[그래프17]설치 후 집중 플레이 기간 [그래프18] 설치 후 집중 플레이 기간 – OS별 [그래프19]설치 후 집중 플레이 기간 – 성별 [그래프20] 설치 후 집중 플레이 기간 – 연령별
이번 조사를 진행하면서 짐작으로 알고있는 내용을 확인하는 내용도 있고, 생각지도 못했던 내용을 알 수 있는 기회도 되었지만
가장 중요한 것은 이 자료가 공유되면서 동일한 데이터를 보면서 다양하게 해석 될 수 있는 기회가 생겼다는 것인 것 같습니다.
혹시 의견 및 제안 내용이 있으시면 언제라도 댓글로 작성해 주시고, 주신 의견은 다음 조사 진행 시 적극 반영하도록 하겠습니다.
대단히 감사합니다.~~^^
▶ 조사제목 : 2012년 1분기 스마트폰 이용자 조사 ▶ 조사대상 : 스마트폰(팟게이트)이용자 총 7,815명 (아이폰 5,175명+안드로이드폰2,027명) 응답
▶ 조사기간 : 2012년 3월29일 ~ 4월13일 ▶ 신 뢰 도 : 95% 신뢰수준의 오차범위 ± 1.11%
진보의 정신이란..
‘더 많은 사람들을 행복하게 만드는 것’일 것이다.즉 자본주의 체제하에서 필연적으로 발생하는 불평등과 여러가지 편차, 이 과정에 소외되는 부분들을
감싸 안는 것, 그것이 진보일 것이다. 그래서 그런 '진보의 정신'을 지지한다. 쉽고 간단한 마음이다.
비록 내가 ‘분배의 정의’를 몸소 실천한다며 당장 내 재산을 다 내놓긴 싫지만, 점진적으로 진보정치인들에 의해 사회구조가 변화되어 종국엔 분배의 정의가 실현된다면 좋겠다는 마음이다. 환경보호를 위해 당장 원시의 삶으로 돌아가긴 싫지만, 점진적으로 환경운동가들에 의해 인류의
의식변화가 이루어져 결국엔 환경파괴가 멈춰졌으면 좋겠다는 마음이다.
그래서 이런 정신을 실현해 줄 진보정당을 기다리고 있었다. 비겁한 우리들이 하지 못하는 걸 대신 해줄 수 있는 세력.
그러나 그간 우리나라의 진보세력은 그저 머리띠와 구호로
상징되는 극렬투쟁의 본산일 뿐 우리가 기다리는 그런 진보세력이 아니었다. 물론 그것이 필요했던 시대도 있었다. 하지만 이제는 그들의 과격투쟁이 오히려
많은 사람들을 피곤하게 하고 불행하게 만드는 시대다.
그런데 지난 총선 전에 반가운 소식을 접했다. 흩어져 있던 ‘유시민 이정희 노회찬 심상정’이 합쳤다는 소식이었다. 별거하던 엄마 아빠가 합친 것처럼 기뻤다. 그들이야말로 진보의 정신을 실현해줄 사람들이라고 믿고 있었는데, 하지만 그들이 따로 흩어져 있어 안타까웠는데, 그들이 드디어 합쳤다는 것이다. 그들이 큰 정치세력으로 자라나 진보의 가치들을 실현해주길 기대했다. 그래서 망설임 없이
통합진보당을 찍었었다.
카메라 앞에서의 이 용감함, 아니 카메라 앞이라 '일부러' 더 용감해진 이 여인.. 공개적으로 목숨을 바쳐야 좋은 곳에 간다고 세뇌된 이슬람의 자살폭탄 聖戰이다. 수십년 동안 전혀 변한 게 없는 NL의 전투강령.. 소름이 돋았었지만 곧 마음을 추스렸다. 안보이던 것이 보이기 시작했기 때문이다.
1.
유노심과 이정희가 합치자 지지율이 세배 가까이
올라갔다. 과거 민노당의 ‘종북’성향을 찜찜해하던 국민들이 유노심이 합류함으로서‘빨갱이 걱정’을 떨쳐버린
거다. 새로운 정당에 종북세력 NL은 극히 미미할 것이라 여겼다.
2.
통진당의 지지율 상승은 유노심의 인기와 역할이 절대적이었다. ‘빨갱이 집단’
소리를 듣던 민노당을 혁파하고 진정한 진보정당을 그들이 일으켰다고 생각했다. 하지만 당내 경선에서는 예상외로 민노당 출신 NL들이 싹쓸이를 했다. NL의 건재에 유노심이 크게 놀라고 상심했다. 곧 NL의
총체적인 부정선거가 있었음을 알게 된다. 하지만 총선이 목전인지라 일단 덮고, 비장의 패로 숨겨둔다.
3.
총선에서 통진당이 약진했다. ‘별거하던 엄마 아빠가 다시 합쳐서 그게 너무 기뻐서
준 표’였다.
외과의사 - 위키피디아 이미지결혼전 연애하던 시절, 지금의 아내가 된 여자친구가 제게 말했습니다. "내 친구중에 아버지가 개원하신 의사인 친구가 있는데 집에서 가족중에 누가 아픈데 어떡해야하냐고 물어보면 그렇게 짜증을 내신대. 그래서 집안사람 누가 아파도 아버지한테는 한마디 못한다고 하더라. 자기는 안그럴거지?" 물론 안그럴거라고 대답했죠. 그땐 연애를 하던 시기이기도 했거니와, 의과대학 졸업에 이은 인턴생활의 철모르는 풋내기 의사시절이었거든요. ...
10.5 Fr, 꽁꽁 닫혀있는 안과 바깥 세상을 연결하는 유일한 통로의 크기. 볼펜보다 얇은 그 길을 통해 우리 환자들은 오늘도 가느다란 목숨을 연명해가고 있다. 살짝 빠지기만 하더라도 의식에 장애가 생기고 목숨이 위태로워질 수 있는 그 싸구려 관은 환자에게 있어서만큼은 금은보화와도 바꿀 수 없는 소중한 것이다. 머리 안에 발생한 출혈을 밖으로 빼내어 목숨을 부지하게 하는 생명의 선인 셈이다. 그래서 그 길을 지키기 위해 중환자실이라는 답답한 공간...
꼬꼬마 시절 저는 결혼에 되게 회의적이었던 터라 좋은 사람이랑 계속 연애하면 되지 왜 굳이 결혼을 해야 할까라는 생각을 많이 했었는데요이런 저런 데이터들을 보면 결혼이 뭔가 좋긴 좋은가보더라고요20년 간의 이런저런 종단/횡단 연구들을 통해서 어느정도 인과관계도 추적해보고 한 끝에 내린 큰 결론은결혼한 사람들이 결혼한적 없거나, 이혼했거나, 별거하거나, 사별한 사람들보다'살짝' 행복하다라는 것입니다 (Diener et al., 1999)무려 18년간...
질병관리본부 탐방기 1. 서론 2009년 신종플루, 2011년 원인미상 중증폐질환.. 본과 4학년이 되었지만 질병관리본부에 대해 아는 것은 이 정도의 키워드에 불과했다. 질병관리본부는 오송 생명과학 단지에 자리잡고 있는 것도 감염병 이외에도 다양한 질환들에 대한 사업을 하고 있는 것도 방문기회를 통해 알게 되었다. 질병관리본부는 보건복지부 산하에 있는 부서로 감염병관리센터, 질병예방센터, 장기이식관리센터가 있으며, 또한 국립보건연구원과 국립검역소가...
<자유하다>라는 표현이 가능한가? 우리는 <나는 자유하다>라고 말하지 않고 <나는 자유이다>라고 말한다. 그런데 근대 국어에서 한자어 명사에다 <하다>를 붙인 동사형들이 많이 생겨났다고 한다. 아마 처음에는 생경했을 것이지만, 그대로 사용하다 보면 익숙해진다. <자유이다>라는 것이 어떤 상태를 의미하는 것이라면 <자유하다>는 어떤 행위를 의미하는 것처럼 보인다. 실존은 본질에 앞선다. 나는 내 본질을 자유롭게 선택할 수 있고, 바로 그렇기 때문에 나는 <자유하다.> 단지 선택할 수 있는 가능성이 아니라, 실제로 내가 선택할 때 비로소 나는 자유이며, <자유한> 존재이다.......
Google's OneBox for instant answers has a new interface that emphasizes the results. Google now displays the answer on the first line and the font size is bigger.
* 첫째(9세)가 과학책을 보다 개구리 해부에 흥미를 느꼈다. 요즘은 해부용 개구리도 5000원에 구입할 수 있다지만, 산 개구리를 해부하고 뒷감당할 자신이 없어서 대신 선택한 것이 냉장 오징어. 둘째(7세)가 아이패드로 보는 것은 어느 블로그에 올라온 오징어 해부 포스팅. 셋째(5세)가 돋보기로 뭘 봤는지는 끝내 알 수 없었다.
* 올해 상반기는 바싸서 포스팅 하나 제대로 못했군요. 6월부터 슬슬 다시 글을 올리도록 하겠습니다.
Google Docs has a new feature that lets you find more information about some of the words from a document and also add content from the Web. The research sidebar can be enabled from the Tools menu or by using the shortcut Ctrl+Alt+R (Cmd +Opt+R for Mac). You can also select one or more words from the document, right click and select "Research" from the menu.
The sidebar includes the top Google search results, image search results, facts, maps, reviews and famous quotes. Click the icon from the search box to restrict the results to images and quotes.
When you mouse over a Web search results, you can preview it, insert a link or cite it. For example, you can select "Google" from a document, press Ctrl+Alt+R, mouse over the top result and click "insert link" to add a link to Google's homepage.
Restrict the results to images to quickly add an image using drag and drop. Google also has a specialized search engine for quotes and you can also add them to your document.
Search for a famous person, a place, a concept or any other entity and Google will display a list of attributes above the search results.
Maybe Google will also add features like translation and definitions to the research sidebar, so you can quickly find them.
randomForest로 부터 데이터 확인 용으로 자주 사용하는 CART 알고리즘 그리고 오늘 처음 본 Conditional Inference Tree까지..
ML알고리즘의 경우 은총알은 없다. 사용 목적에 맞으면 그게 장땡인거다. 게다가 사실 빅 데이터를 가지고 분석을 한다면 내부가 블랙박스로 되어 있어서 어떻게 돌아가는지 안보이는 알고리즘 보다는 투명한 Tree 계열 알고리즘이 더 낫다고 생각한다. 만일 모델 빌드에 실패 하더라도 왜 실패하는지 그리고 어떤 방향으로 나아가야 되는지 룰을 보고 확인 가능하기 때문이다.
Conditional Inference Tree는 통계학적인 가설검정의 기법이 가미된 트리로서 각 노드에 유의수준값이 표시된다. 뭐 통계학 개론 정도 보신 분들이라면 이게 어떤걸 의미하고 왜 노드에 이런게 있는지 짐작을 하실거라 생각한다.
특정 유의수준 이상으로 허용을 하지 않는 선에서 트리는 자라게 되고 대부분 0.05 유의수준을 기준으로 하니 overfitting이 되는 경우는 그다지 없을 것이다.
CT에서는 잘 보이지 않는 자잘한 암세포들이 복막에 들러붙어 장이 제대로 운동하지 못하게 한다. 그래서 어떤 암이든 복막으로 전이가 된 환자들은 잘 못 먹고 토하고 자꾸 배가 아픈게 비슷하다.
치료는 금식하고 장을 쉬어주는 것.
장을 쉬게 해준 다음
다시 먹어보고 배가 다시 아픈지 어쩐지 보는 것이다.
배가 너무 부르고 장운동이 안되면 콧줄을 꼽아야 한다. 콧줄이 목으로 넘어가는 느낌은 매우 불편하고 답답하고 아프다. 그렇게 불편한 채로 물도 못 마시고 몇일을 기다려보는 것이다. 장이 풀릴지 어쩔지 기약없이.
그녀는 난소암 복막 전이로
항암치료 했다가 좀 쉬다가 또 나빠지면 했다가 좀 쉬다가 그렇게 지내기를 5년이 지났다.
항암치료를 하면 반응이 좋다. 그렇지만 시간이 지나면 나빠진다. 그것이 재발 후 그녀의 시간들이다.
그녀는 인생의 목표가 있다. 아들이 대학갈 때까지 엄마가 곁에 있어주는 것.
그래서 어떤 치료를 해도 힘들다고 하지 않는다. 열심히 먹고 운동한다.
항암 치료 중 패혈성 쇼크가 와서 응급실에 온 적이 있었다. 혈압이 떨어지고 의식이 혼미해 질정도였다. 카테터에서 계속 균이 자라서 카테터를 빼고 한달가까이 항생제를 쓴 적도 있다. 그녀는 절대 힘들다고 말하지 않는다. 선생님 저 열심히 노력할께요. 꼭 치료해주세요.
그렇지만 최근 몇 개월 그녀는 응급실행이 잦다. 항암제 반응이 떨어지는지 종양표지자 수치도 오르고 장폐색이 반복된다. 이미 쓸 수 있는 항암제는 다 썼다.
병원 오기 싫어서 몇일을 참다가 응급실로 오고 만다. 2-3일 굶고 콧줄 꼽고 있다가 좀 나아지면 퇴원하기를 수차례.
나는 그녀에게 제안하였다. 장루를 빼는 수술을 합시다.
대장암 환자처럼 장루를 빼자는 말에 어리둥절해 한다. 장폐색을 반복적으로 일으키는 부위를 찾아 그 부위를 절개하고 그 부위를 복벽으로 연결하여 장루를 설치하는 수술을 제안하였다. 그렇게라도 해서 음식을 먹고 배설하는 과정을 용이하게 해야 할 것 같았다.
우리나라 환자들은 장루를 참 싫어한다. 나도 싫다. 그래도 계속 못 먹고 영양제만 맞으면서 항암치료를 하는 것은 더 이상 어려워 보였다. 환자는 장루 수술에 대해 이틀간 고민하였다. 배도 아픈데 골치아픈 고민을 하려니 얼굴이 더 헬쓱해진다.
그리고 수술을 하겠다고 했다.
내 마음 속으로
복막전이가 생각보다 심하면 장루를 빼는 것 자체도 어렵고, 장루를 빼고 나서도 장 기능이 원할치 않아 지금 노리는 목표 – 장루 후 잘 드시도록 하는 거-가 달성되지 않을 가능성도 있음에 대해 걱정한다. 환자에게도 장루를 빼는 수술이 항상 100% 성공하는 것은 아니라고 운을 띄웠지만 환자는 정작 그 말의 의미를 내 맘 그대로 이해한 것 같지는 않았다.
그리고 내가 우리 외과에서 제일 존경하는 H 선생님이 수술을 해주셨다. 수술 후 통증도 심하고 고생했었다. 겨우 퇴원하였다.
그리고 그녀가 오늘 생글생글 웃으면서 외래에 왔다.
선생님, 왜 이렇게 먹고 싶은게 많아요? 떡볶이도 먹고 라면도 먹고 어제는 수제비도 먹었어요.
많이 먹으면 장루로 많이 나오긴 해요. 그래도 어디에요? 이런 음식 먹어본지가 얼마만인지 모르겠어요. 먹는 즐거움이 이렇게 큰건지 몰랐네요.
얼굴에 활력이 있다.
아직 야윈 상태가 다 해결된건 아니지만
외래를 걸어들어오는 그녀의 발걸음이 가볍다.
진통제도 많이 줄였다.
종양수치는 좀 올랐다.
우리는 항암치료 하지 않고 좀 더 쉬기로 했다.
그녀도 더 이상 두려워하지 않는다.
일정 맞춰서 항암제를 맞는 것만이 능사가 아니라는 걸 알게 된 것 같다. 더 이상 초조해하지 않는다.
Org Mode is a personal information manager for the Emacs text editor. People have contributed a ton of useful features to it over the years, and the development shows no sign of slowing down. One of the features I’ve been playing around with is the ability to track habits.
Org habits are recurring tasks. For example, everyday, I want to:
take my vitamins
capture a quick note about the day, and
plan the next day
Every week, I want to:
talk to my mom
check the org-mode mailing list
write a weekly review and plan the next week
clear and reorganize my belt bag
clear my inbox
write a bunch of blog posts
back up my computer
Once a month, I want to:
update the topical index for my blog
review and uninstall programs
balance my books and update my budget
review the past month and plan the next
check the library for new books
Org habits let me manage my task list without cluttering future days with tasks. The Org agenda view displays habits that are due today, indicating consistency with colour. In particular, it shows overdue days in red, so you can get the Seinfeld-esque pleasure/commitment-device of not breaking the chain.
Here’s a view from Sunday:
2 days-agenda (W19-W20):Sunday 13 May 2012 8:00...... ---------------- 10:00...... ---------------- 12:00...... ---------------- 14:00...... ---------------- 15:57...... now - - - - - - - - - - - - - - - - - - - - - - - - - 16:00...... ---------------- 18:00...... ---------------- organizer: 22:00...... TODO Capture a one-sentence note ! organizer: 22:00...... TODO Plan the next day **************! organizer: Scheduled: TODO Make a list of recipes I want to learn organizer: Scheduled: TODO Write a bunch of blog posts:writing: organizer: Scheduled: TODO Set up WordPress as my backup systemMonday 14 May 2012 W20 organizer: Scheduled: TODO Build Emacs interface so that I can have Org automatically switch my tasks
To use Org habits, customize org-modules and enable the habit module. To set something as a habit, use C-c C-x p (org-set-property) to set the STYLE property to habit. For more information, you should definitely check out the Org manual’s section on habits.
Yay Emacs and the people who contribute to it!
Read the original or check out the comments on: Org-mode and habits (Sacha Chua's blog)
Yesterday I visited the ever popular NYU ITP bi-annual show which is a showcase of the students' experimental and ingenious interactive work.
I stopped to talk to data visualization student and self-tracker, Doug Kanter, about his work. His first and smaller piece was about the war in Iraq. The image above depicts the number of wounded US soldiers by state (and territory) using the red stripes. The stars show the number of soldiers killed. I'm sure we could quibble about labels and where the bar chart starts, but to me, the tattered appearance of the flag created by data about war is very arresting.
Doug's more developed work dealt with his self-tracked health data. He's a type-1 diabetic and monitors his blood glucose, insulin dosage, and diet among other things. His visualization showed three months worth of data by which he says he was able to see how a low-carb diet helped keep his blood sugar in check. Doug's blog post detailing his process and visualization is worth a read.
The ITP Spring Show runs through this evening at 721 Broadway in NYC. Over 100 projects are on display making this a must see of interactive innovation.
The whole "everyone should learn programming" meme has gotten so out of control that the mayor of New York City actually vowed to learn to code in 2012.
A noble gesture to garner the NYC tech community vote, for sure, but if the mayor of New York City actually needs to sling JavaScript code to do his job, something is deeply, horribly, terribly wrong with politics in the state of New York. Even if Mr. Bloomberg did "learn to code", with apologies to Adam Vandenberg, I expect we'd end up with this:
10 PRINT "I AM MAYOR"
20 GOTO 10
Fortunately, the odds of this technological flight of fancy happening – even in jest – are zero, and for good reason: the mayor of New York City will hopefully spend his time doing the job taxpayers paid him to do instead. According to the Office of the Mayor home page, that means working on absenteeism programs for schools, public transit improvements, the 2013 city budget, and … do I really need to go on?
To those who argue programming is an essential skill we should be teaching our children, right up there with reading, writing, and arithmetic: can you explain to me how Michael Bloomberg would be better at his day to day job of leading the largest city in the USA if he woke up one morning as a crack Java coder? It is obvious to me how being a skilled reader, a skilled writer, and at least high school level math are fundamental to performing the job of a politician. Or at any job, for that matter. But understanding variables and functions, pointers and recursion? I can't see it.
Look, I love programming. I also believe programming is important … in the right context, for some people. But so are a lot of skills. I would no more urge everyone to learn programming than I would urge everyone to learn plumbing. That'd be ridiculous, right?
The "everyone should learn to code" movement isn't just wrong because it falsely equates coding with essential life skills like reading, writing, and math. I wish. It is wrong in so many other ways.
It assumes that more code in the world is an inherently desirable thing. In my thirty year career as a programmer, I have found this … not to be the case. Should you learn to write code? No, I can't get behind that. You should be learning to write as little code as possible. Ideally none.
It assumes that coding is the goal. Software developers tend to be software addicts who think their job is to write code. But it's not. Their job is to solve problems. Don't celebrate the creation of code, celebrate the creation of solutions. We have way too many coders addicted to doing just one more line of code already.
It puts the method before the problem. Before you go rushing out to learn to code, figure out what your problem actually is. Do you even have a problem? Can you explain it to others in a way they can understand? Have you researched the problem, and its possible solutions, deeply? Does coding solve that problem? Are you sure?
It implies that there's a thin, easily permeable membrane between learning to program and getting paid to program professionally. Just look at these new programmers who got offered jobs at an average salary of $79k/year after attending a mere two and a half month bootcamp! Maybe you too can teach yourself Perl in 24 hours! While I love that programming is an egalitarian field where degrees and certifications are irrelevant in the face of experience, you still gotta put in your ten thousand hours like the rest of us.
I suppose I can support learning a tiny bit about programming just so you can recognize what code is, and when code might be an appropriate way to approach a problem you have. But I can also recognize plumbing problems when I see them without any particular training in the area. The general populace (and its political leadership) could probably benefit most of all from a basic understanding of how computers, and the Internet, work. Being able to get around on the Internet is becoming a basic life skill, and we should be worried about fixing that first and most of all, before we start jumping all the way into code.
Please don't advocate learning to code just for the sake of learning how to code. Or worse, because of the fat paychecks. Instead, I humbly suggest that we spend our time learning how to …
Research voraciously, and understand how the things around us work at a basic level.
[advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position!
I'm going to be away for a couple of weeks, with little to no Internet access most of the time, so I've asked Kim Rees to step in while I'm gone. She's the co-founder of Periscopic, one of my favorite information visualization firms, and she was the technical editor for Visualize This. You're in good hands.
charsyamtwitter1twitter2twitter3twitter4twitter5redis_flushdbtwitter6
시각 장애인이 웹 또는 휴대폰을 이용하면서 겪은 애로사항을 공유하기 위한 간담회를 다녀왔습니다.
