요즘 아버지께서 족보 관련 문제로 골머리를 썩고 계셨는데, 바로 이것 때문이었다.
다른 종친회는 관련 문서의 전자 포맷도 배포하는 것으로 오늘 파악할 수 있었는데, 전자 족보 간행 경험이 없어서인지 어떤 곳에서도 담양 전씨 수단 양식을 찾을 수 없었다. 결국 아버지와 차를 몰고 종친회 사무소에 방문해 포맷을 복사해 올 수 있었다.
힘들게 얻었지만, 아마도 다른 분들이 족보 관련된 포맷이 필요할지 몰라 이곳에서 공유한다.
블로그의 성격과 전혀 맞지 않지만 내가 이용할 수 있는 가장 검색엔진 친화적인 매체가 이것 뿐이라서 어쩔 수 없이 이곳에 올린다. 간단한 검색어만으로 쉽게 찾을 수 있을 거라 예상한다.
종친회 방문해서 오는 길에 운좋게도 말로만 들었던 화봉재를 볼 수 있었다. 화봉재는 담양 전씨 서당으로 알려진 곳으로 시 지정 문화재이다. 조만간 오늘 찍어둔 사진으로 위키페이지나 만들어 둬야 겠다는 생각이 든다.
UseR! 2012의 abstract submition deadline에 맞춰서 한글 Text Mining에 대한 내용 발표를 하기 위해 abstract를 넣었다.
사실 회사 차원에서는 RHive를 발표하기 위해 팀원분과 함께 작업을 했고, 만일 가게 된다면 내 나름대로 관심이 있는 분야도 겸사겸사 발표해 보려고 올렸다. 재수가 좋다면 떨리는 가슴을 안고 미국 테네시주로 향하게 될 것이고 아니면 마는 거고…
RHive는 반드시 오럴로 채택이 될 듯 하지만, 내것은 poster 혹은 떨어질 수도 있을 거란 생각도 든다.
사실 여기 가서 R core팀 분들과 존경하는 Hedley교수를 개인적으로 만나고 싶은 게 가장 큰 목적이긴 하다. 메일로 그리고 github에서 이런 저런 이야기를 하면서 딱딱하긴 했는데, 직접 보고 이야기하면 나중에 뭔가를 함께 하기도 참 좋을 거 같다는 생각을 해봤다.
일단 내가 올린 abstract 링크를 올려본다.
제 3회 Meetup을 아래와 같이 공지합니다.
일시 : 2012. 03. 22. 목요일 19:00~20:30
장소 : NexR 회의실 (강남역 2호선 부근: 서초구 서초동 1321-6 동아타워 4층 KT Cloudware)
(http://me2.do/5RCp3h)
주제 : R의 한글화 및 R 그래픽스
발표자 :
신종화님 : ”Contributed Packages의 번역: Rcmdr을 중 심으로”
유충현님 : “사용자 정의 그래프 함수 만들기”
전희원님 : “ggplot2″추가로 발표할 주제가 있으신 분들께서는 댓글을 달아주시기 바랍니다. 그러면 발표를 하실 수 있는 시간을 만들어 드리겠습니다.
저녁거리가 될 수 있도록 간단한 다과를 준비하겠습니다.
참석을 원하시는 분들도 댓글을 달아주시기 바랍니다.
두 번째 meetup에서는 일이 있어서 참석을 못했는데, 1회 meetup때 KoNLP 소개에 이어 3회 meetup에는 ggplot2라는 R visualization library에 대한 소개를 해보려 한다.
개인적으로 이 ggplot2를 학습하게 된 동기는 최근 나오는 R 관련 책에서 기본 라이브러리로 다루어지는걸 많이 봐왔기 때문이다. 독자에게 양해를 구하지 않고 사용해도 될 정도로 라이브러리의 인기가 높아진 결과라 생각한다.
이번 발표도 지난번과 같이 발표 자료 없이 RStudio에서 코드를 이용해 소개를 할 예정이다.
Tags: R
최근 7th ACC의 설문조사에서 발표자들 중에서 1등을 했다는 연락을 ZDnet에서 받아 기자분들이 보고서와 함께 방문을 했었다. 발표를 하면서 느낄 수 있었던 열의가 그대로 설문조사로 표출되는 개인적으로 참 하기 힘든 경험을 했었다.
데이터 분석, 데이터 과학자의 중요 덕목으로 Presentation Skill일 손꼽고, 작년부터 데이터 과학자로 일하면서 이 부분에 대해서 많은 고민을 해왔는데, 중요한 방점하나를 찍은게 아닌가 하는 생각을 해본다.
그날 성공적인 발표를 할 수 있었던 이유는 단 하나였다.
“여기온 청중들이 듣고 싶어 하는 내용이 무엇인가?”
그리고
“그 내용들 중에서 나만이 해줄 수 있는 이야기는 무엇인가?”
이런 고민 끝에 빅 데이터 분석 경험에 대한 공유를 잘 할 수 있었던 거 같다.
화려한 PPT도 중요하다고 생각한다. 하지만 그보다 더 중요한 것은 내가 청중들에게 이야기 해줄 수 있는 내용이 그들에게 어떤 가치를 제공할 수 있는지 고민하는 일이라 생각한다. 하지만 이도 밑천이 없으면 고민도 할 수 없다. 따라서 좋은 경험을 많이 하고 여러 현존하는 문제들에 평소에 고민을 하지 않으면 안될 것이다.
Tags: presentation
Strata 컨퍼런스에서 있었던 논쟁중에 하나로 위 제목과 같은 내용의 대화가 우리가 익히 알고 있는 사람들에 의해서 논의 되었는데, 그 결론이 참으로 기억해 둘만해서 올려본다.
the data science debate: domain expertise or machine learning?
debator들은 아래와 같다.
Drew Conway, Ph.D. Candidate at NYU, Data Scientist at IA Ventures
DJ Patil, Data Scientist in Residence at Greylock Partners
Amy Heineike, Director of Mathematics at Quid
Weighing in against the motion (e.g. favoring machine learning skills) were:Pete Warden, CTO of JetPac
Pete Skomoroch, Principal Data Scientist at LinkedIn
Toby Segaran, Author of Collective Intelligence and Google Engineer
Conway, Segaran 이 두 사람만 책으로 만나본 사람들이다. 물론 Conway가 가장 절묘한 코멘트를 날리긴 했지만…
메모해둘 부분은 아래와 같다.
One of the conclusions reached was that, when a problem is well-structured (or to Drew Conway’s point, when a good question is posed), it is much easier for machine learning to succeed. Kaggle’s strength as a contest platform is that domain experts have already framed the problem: they choose the features of the data to use (feature engineering or “feature creation”, as Monica Rogati calls it) as well as the criteria for success. This is the first, hardest step in any data science project. After this, machine learners can step in and develop the best algorithms for classifying and predicting new data (or, less usefully, explaining old data).
Thus who you decide to hire as your first data scientist — a domain expert or a machine learner — might be as simple as this: could you currently prepare your data for a Kaggle competition? If so, then hire a machine learner. If not, hire a data scientist who has the domain expertise and the data hacking skills to get you there.
사실 Kaggle에서 우승하는 사람들은 문제의 도메인과 거의 상관이 없는 사람들이었다. 오히려 머신러닝 기술을 더 잘 다루는 사람들이라 말할 수 있는데, Kaggle 대회는 이미 도메인 전문가들이 제공한 feature들과 여러 정보를 문제와 함께 제공하고 있다고 볼 수 있다. 그 제한된 sandbox에서 정말 잘 할 수 있는 사람은 오히려 머신러닝 전문가가 아닐까? 왜냐면 feature를 설령 발굴 했다 하더라도, 제공된 데이터에 없기 때문이지…
그런데 문제는 대부분의 현실 문제가 저렇게 well-defined 된 것들이 아니라는 것이다. 스스로 feature를 발굴하고 정의하고 질문을 함으로써 문제를 정형화시키는 능력을 가진 사람은 오히려 도메인 전문가들의 영역이 아닐까 한다.
머신러너 혹은 도메인 전문가도 도메인의 문제를 풀기 위한 탐구 열정과 노력이 필요한데, 그런 curiosity를 가진 사람을 찾겠다는 Patil의 의견에도 전적으로 동의하는 바이다.