에어컨 꺼짐 예약을 목표로 하는 기상 시각 한 시간 전으로 맞춰 놓으면 된다. 며칠 간 이상하게 일찍 눈이 떠 지길래, 원인이 뭘까 분석해 봤더니, 위와 같은 결론을 얻었음. 그리고 오늘은 꺼짐 예약을 과도하게 일찍 맞춰 놓은 탓에.. ㅠ.ㅠ
#1. 요즘 테니스를 배우고 있는데, 이제 테니스의 왕자!! 까지는 아니고, 드디어 기계님이 공을 던지면 80% 정도는 안정적으로 넘기는 듯 ㅎㅎ 그런데 언제쯤 랠리 해 보려나. #2. 회사 보안 정책 상, 3개월 (6개월이던가?) 에 한 번씩 비밀번호를 바꿔야 하는데, 이 비밀번호가 은근히 연동되는 곳이 많아서, 한 번 바꾸려면 어마어마하게 귀찮은 작업이 동반된다. 사내 무선랜 접속을 위한 아이폰 설정 변경, 노트북 설정 변경, 이메일 비밀번호 변경에 따른 아웃룩 설정 변경, 사내 사이트 접속을 위해 설정 해 둔 자동 접속 설정 변경 등등.. 게다가, 최근에 사용한 비밀번호 세 개는 사용할 수 없기 때문에 매번 새로운 걸 생각해 내야 한다. 처음에는 성실하게 회사 보안 정책을 따라줬으나, 결국 최근에 ..
오랜만에 여자친구랑 연극을 보고 왔다. 연극에 대한 사전 정보는 전혀 없었고, 그냥 여친이 재밌다는 얘길 어디서 듣고 와서 예매를 했다. 아무것도 모르고 보다 보니, 처음에는 이 연극이 삼촌 팬들의 극성스러운 팬모임을 희화화 한 연극인가 싶었다. 그런데 그러기에는 개그가 좀 많이 부족해 보였고, 스토리도 많이 부실하게 느껴졌다. (단순히 그런 연극이었다면 훨씬 더 재미있게 만들 수 있었을 텐데!) 처음 한 시간은 도대체 이게 뭐하는 연극인가 싶을 정도.. 그런데 차차 스토리가 연결이 되면서, 초반에 깔아 놨던 많은 이야기들이 뒷부분에서 복선으로 살아나긴 한다. 결국 끝나고 보니 범인 찾기 류의 연극이었다. 예전에 봤던 쉬어매드니스처럼 아예 오픈 엔딩은 아니였고, 결론도 남.. 장점) 컬처스페이스 엔유 공..
언제까지 야근인지 뭔가 길게 쓸 힘도 없다 그래도 이제 발표자료는 다 만들었고, 발표 연습 빡세게 하고, 이제 발표만 하면 됨 ㅜ.ㅜ 우리 팀,, 아니 우리 회사에서는 nutch에 대해서 내가 제일 많이 안다고 말할 수 있음 ㅎㅎ 나중에 여건이 허락하면 블로그에도 올려야지 좋은 소식 한 가지 : 예전 회사에서 **를 지급하겠다는 연락이 왔다. 역시 법이랑 친한 친구가 한 명 정도는 있어야 함. P군! thanks 나쁜 소식 한 가지 : 저거 받기 위해서 무려 회사에 직접 방문해서 합의문에 인감 도장을 찍으랜다. 에휴 –.- 또 이렇게 아까운 휴가가 날아가는구나.
hadoop은 기본적으로 input split에 의해 계산된 각 split에 대해 하나의 map task를 생성한다. (여담이지만, 실제 map task의 개수는 mapred.map.tasks의 값이나 setNumMapTasks() 에 의해 결정되지 않는다. 자세한 이야기는 여기 참조) InputSplit은 딱 두 개의 method를 가진 abstract class로 정의되어 있고, 각 method는 다음과 같다. public abstract long getLength(); // split의 size를 반환 public abstract String[] getLocations(); //split의 data가 저장된 node들을 반환 실제 split을 구현한 class로 FileSplit class가 있다...
#1. 원래 우리 팀이 그렇게 바쁜 팀은 아닌데,, 오늘 야근을 하다 보니 새벽 한 시 –ㅅ-; 딱히 누가 시켜서 하는 야근이 아니고, (물론 원인 제공을 한 사람은 있다) 그나마 평소에 해 보고 싶던 거라서 다행스럽긴 하지만.. 그래도 계속 이런 식이면 몸이 축날 것 같아서 앞으로는 좀 자제해야겠다. 아.. 그나저나, 나랑 코드가 안 맞는 그 분은 계속 날 긁는데 –_- 정말;;; 힘듦. 발표를 시키는 이유가 좋은 내용을 팀에 공유하기 위한 건지, 나를 까기 위한 건지 잘 구분이 안간다. 이런 식으로 자극을 줘서 열심히 일하게 만드는 건가? 물론 효과가 없는 건 아니지만, 나의 짜증은 계속 쌓여감 –_- #2. 야구 9단. 요즘 바빠서 거의 관리를 못 해 주고 있었는데.. 오늘 하루 전적이 너무 화려하..
오밤중에 설거지하고 났더니 아주 그냥 뿌듯하구만. 기념으로 잡담 몇 가지. #1. 오늘 우리 센터장님 발표하시는 걸 들었는데, 정말 발표 끝내주게 잘하신다. 컨텐츠도 충분히 있었고, 준비된 것인지 애드립인지 구분이 안 가는 자잘한 유머들과, 청중들을 들었다 놨다 하는 발표의 호흡까지.. 사실 센터장님과 직접 대면할 일이 잘 없어서 ^^; 리더십 이런 부분(물론 잘 하신다고 들었음)은 잘 모르겠고, 발표하시는 모습은 정말 배우고 싶다. 노력하면 갈 수 있는 경지인가? 타고나는 거면 정말 안습인데 ㅎㅎ #2. 개인프로젝트를 다시 시작하기로 마음을 먹었는데, 오늘 황당한 기사를 보았다. 내가 구현하고자 하는 모습과 최종 goal이 비슷한데, 이 사람은 실체가 전혀 없는 사기꾼 –_-; 뭔가 시작하기 전부터 기..
아.. 지난 주랑 이번 주랑 진짜 폭풍 야근 –ㅅ- 야근비조로 나오는 교통비만 모아도 꽤 돈 될 듯 ㅎㅎ 팀장 겸 랩장님이 출장 가셨으니 편하겠군! 이라고 생각하였으나, 2주간 출장을 마치고 돌아오셨을 때, 뭔가 진행된 사항을 보여드려야 한다는 압박감에 –_-;; 그런데 의외로 mysql에서 문제가 발생하여 T_T 삽질로 시간은 무진장 보냈으나, 정작 성과는 별로 없는.. ㅋㅋㅋ 아우 힘들다 힘들어
주의 : 아래 내용들은 애플의 keynote를 보고 적은 개인적인 단상들이며, 근거 없는 추측들이 많습니다. :) iMessage iOS 사용자들끼리만 사용할 수 있는 폐쇄적인 메신저라며, 평가절하 하는 사람들도 있지만, 내 생각엔 충분히 성공할 수 있을 것 같다. iMessage가 기본 SMS앱과 통합되어 있고, 3G/WiFi 제약도 없고, 별도의 설치 과정이 필요 없다는 사실을 기억해 보면, 아직까지도 “어플”에 익숙하지 않은 많은 사용자들을 끌어들일 수 있을 것이다. 핵심은 대다수의 사용자들이 이게 iMessage인지, SMS인지 모르고 사용한다는 점이고, 그렇게 서서히 퍼져나갈 듯.. iMessage가 대세가 되면, 당연히 안드로이드도 기본 SMS앱에 google talk을 통합할 것이고, (이미..
우선 전세계 버전. 많이들 인용하는 Net MARKETSHARE 자료 MS의 인터넷 익스플로어가 아직까지는 전체의 반 이상을 점유하고 있다. 그런데 이 그래프만 봐서는 추세를 보기가 힘드니.. Net Markershare에서 제공하는 자료를 좀 가공하여, 그래프로 다시 그려 보았다. 전세계 브라우저 점유율 추세 그래프. Net Marketshare 제공 자료 재 가공 몇 가지 시사점 IE의 시장 점유율은 2년 째 지속적으로 하락하고 있음. Firefox는 현상 유지. Chrome이 출시되면서, Firefox의 점유율을 가져올 것이라는 예상이 많았는데, 이 데이터만 놓고 보면, 예상이 틀린 듯.. Chrome이 2008년 9월에 출시된 것을 감안하면, 3년도 채 되지 않아, 전체 점유율의 10%를 넘어섬...
우선 기존 Gecko와 Firefox 버전업 속도를 한 번 보자. Gecko Firefox release date diff_date 1.0 1 2004-11 1.8 1.5 2005-11 365 1.8.1 2 2006-10 334 1.9.0 3 2008-06 609 1.9.1 3.5 2009-06 365 1.9.2 3.6 2010-01 214 2.0 4 2011-03 424 5 2011-06 92 6 2011-? 7 2011-? http://en.wikipedia.org/wiki/Gecko_(layout_engine) 보다시피 원래 Firefox의 major 업데이트 기간은 짧으면 200일, 길면 400일이 정도였다. 그랬던 Firefox가 앞으로는 release process를 바꿔서 약 6주~12주 간..
* 정보 공유 차원에서 오늘 한 삽질을 기록으로 남김 상황 map/reduce 프레임웍이 필요한 것은 아니고, 단순하지만 처리하는데 오래 걸리는 작업들을 여러 컴퓨터에 분산하여 처리하고자 함. reduce task 개수를 0으로 주고 mapper only로 설정하여 작업을 시작. 문제 : 현재 hadoop의 scheduler는 preemptive 하지 않기 때문에, 한 번 map task가 시작되면, priority가 낮더라도 해당 map task가 끝날 때 까지 계속 진행됨. 덕분에 나의 단순하고 오래 걸리는 작업들이 한 번 hadoop에서 돌기 시작하면, 다른 긴급한 작업들이 처리되지 못하는 상황이 발생! 시도된 해결책 나의 job에서 동시에 실행되는 map task 개수를 제한하여, 다른 긴급한 작..