함께 일해요.

17 Jul , 2014  

wpid-20140716_235301.jpg

지난 주 회사 라이브러리에서 빌려온 책.

“화성에서 온 남자, 금성에서 온 여자”의 저자가 직장 생활을 기준으로 남녀가 커뮤니케이션 하는 방식을 다룬 책이다.

같은 이야기를 중복하고 있다는 느낌이 들기도 하지만 결과 중심의 남자와 관계 중심의 여자가 어떻게 이야기하고 느끼는지 잘 설명하고 있다.

상대가 어떤 반응을 보일지 몰라 여직원들에게 부정적인 피드백을 보이기 힘든 내 모습이 떠오르면서 그 여직원들이 왜 그렇게 부정적인(?) 피드백을 내게 보였는지 어느정도 이해가 되었다.

이 책을 읽고 어제 회의에 들어갔더니 책에서 지적한 결과지향적인 행동들을 내가 그대로 하고 있더라. 물론 배운대로 공감을 얻기 위한 몇가지 행동을 취해 보았다. 역시 쉽지 않더라. 계속 결론을 도출하고 있는 내 모습을 확인했다. ㅎㅎ

단순한 내용이지만 느끼는 것이 많은 책이었다. 하지만, 끝까지 정독할 필요는 없는 책인 것 같다.

,

다이어리

현도가 죽었다…

14 Jul , 2014  

flower

항상 피곤한 표정이지만, 상냥하게 웃어주면서 열심히 일하던 현도가 오늘 오전에 응급실에 실려갔고, 숨을 거두었다고 한다.

늦은 시간까지 회사에 남아봐야 뭐하나 하는 생각에 오늘은 일찍 퇴근했다. 저녁에 회사에 남아서 하는 일도 반 이상은 취미 생활이지만…

남의 이야기가 아닐지 모른다는 생각이 들어서, 오늘은 그냥 일찍 퇴근했다…

현도가 남긴 트위터의 마지막 글들이 그의 죽음과 무관하기를 바라는 마음으로…

포토모자이크

포토 모자이크에 Mahout을 적용한다면?

4 Jul , 2014  

mahout-logo-200

Mahout이라는 머신 러닝 프로덕트가 있다. 보통 이커머스에서 상품 추천을 위해 사용하는 것 같은데 꽤나 쉽게 적용할 수 있나보다. 일일이 K-Mean을 비롯한 다양한 분류 알고리즘을 이용하는 것보다 나은 선택이 될 수 있다.

만약 유사한 이미지를 추천할 수 있다면, 포토모자이크에서 보다 자연스러운 이미지를 만들어 낼 수 있을 것으로 기대된다.

,

다이어리,작업

너무 redis에 집착했어…

4 Jul , 2014  

현재 만들고 있는 로그 수집기는 redis를 저장소로 사용하고 있다.

로그를 수집한다기 보다 클라이언트에서 정제해서 보내준 데이터를 시간 별로 카운팅한다는 것이 더 적절한 표현이다. 로그 특성상 엄청난 호출이 예상되고, RDBMS에서 레코드의 값을 올리는 것보다 redis의 증가 명령이 더 빠를 것이라고 예상했기 때문에 redis를 선택했다.

시간별 오류 목록을 이메일로 발송할 때까지는 큰 어려움이 없었는데, 막상 카운트를 취합하고 그래프로 표현하려니 손이 더 간다. 당장 가장 호출이 많은 N개와 그 나머지를 판단하려니 일일이 코드로 작성해야 하는 번거로움이 발생했다.

그래서, 이번에는 redis에 저장한 정보를 주기적으로 mysql에 이관하고 query를 이용해 정보를 취합할 생각이다.

막상 문제에 부딪혀 보니 저장소의 특징을 무시한 채 좋아하는 쪽으로 마음이 기울었던 것이 아닌가 하는 생각이 든다.

, ,

동영상,음악

Epik high – 우산 (Feat. 윤하) 보기

4 Jul , 2014  

이번에 윤하가 다시 부른 신곡보다 원곡이 더 마음에 든다. 랩 또는 에픽하이를 좋아해서 그런 것일 수도 있다.

,

게임,다이어리

현역 PS2

23 Jun , 2014  

image

처가에서 아직도 현역으로 뛰고 있는 PS2.

이젠 더 이상 게임을 실행하지 않지만 아이들의 애니메이션 DVD를 꾸준히 돌리고 있다.

인터넷으로 검색해보니 2004년에 출시. 이 상태라면 큰 아들이 초등학교에 들어갈 때까지도 쓸 것 같은데? 벌써 10년된 기계인데 오래도 간다. ㅎㅎ

,

다이어리

Middleware에 Log 수집기 적용

20 Jun , 2014  

현재 운영 중인 MW에 Log 분석 기능을 적용했다. 정확히는 지난 번에  python으로 작성되어 있는 서비스를 Java로 재구성하였다.

기존 서비스는 각각의 서버에서 Log를 분석하고 SMTP를 통해 직접 이메일을 발송하는 구조라 구조가 단순한 반면 각 서버마다 이메일을 보내게 되어 너무 많은 메일이 발송되는 불편함이 있었다.

이번에는 Java로 client와 server를 모두 구현하였다. Client는 Log를 분석하여 지정된 형식으로 server에 발송하고, server가 분석 및 이메일 발송을 처리하고 있다.

이미 알려진 여러 시스템들처럼 client가 Log를 가공하지 않고 보내는 방법이 있지만 server가 처리할 일이 많아져서 1차적인 처리는 client에서 담당하였다.

하루에 한 번씩 호출 횟수를 발송하는 기능은 용량 제안으로 인해 실패하였다. 다시 생각해보니 이메일 발송은 효율적이지 못할 것 같고 대신 모니터링 또는 레포팅을 담당하는 웹 서비스가 더 유용할 것 같다.

또한 한 시간이 한 번씩 오류로 추정되는 호출 통계를 보내고 있는데 나중에 이야기할 경고 메일에 가려 현재는 효용성이 낮은 상황이다. 이 또한 웹 서비스로 이전해야 할 것 같다.

마지막으로 알 수 없는 오류 또는 DB 오류를 5분마다 이메일로 발송하고 있다. 이번 점검일에 큰 업데이트들이 있어서 더욱 유용하게 사용되었다. 오류 메시지가 자주 오니까 부담스럽기는 했지만 덕분에 다들 빨리 수정해서 가장 효과가 있었다.

이제 웹 서비스를 만드려고 하니 김태윤 과장이 이야기 했던 것처럼 API server가 필요해졌다. 덕분에 오늘 늦게까지 code refactoring을 하게 되었다. ㅎㅎㅎ

이번에 처음으로 혼자서 Java product를 만들면서 많은 것을 배우고 있다. 이번에 netty 4를 썼는데 내부에는 비동기 처리가 적어 효율적이지 못하다. 또헌 속도를 고려해 객체를 생성할지 아니면 하나를 재사용 할지 고민되는 부분이 많다. 또한 class 구성도 딱히 맘에 들지 않아서 저녁 늦게까지 수정을 했다.

웹 서버가 부를 수 있는 API를 만드려고 봤더니 기존 MW처럼 dispatcher를 구성하고 reflection을 이용하게 될 것 같다. 처음부터 분리했으면 덜 수고로웠을텐데… 아쉽기도 하지만, 처음부터 여러 product로 분리할 상황이 못되었다. 이제 해야지 뭐… ㅎㅎ

여하튼 잘 쓰고 있으니 기분이 좋다.

,

다이어리

이사 예정

16 Jun , 2014  

Moving Truck

이번 9월에 이사 가기로 했다. 무엇보다 큰 아들이 아빠를 많이 찾은 덕분(?)에 처가 식구들까지 모두 이동하게 되었다.

지난 토요일(6/14)에 그동안 아내가 봐둔 상현동을 둘러보다가 결정하게 되었다. 원래는 동네 파악하는 정도로 끝날 줄 알았는데, 예상보다 넓은 평수 전세가가 높지 않고 그 날 결정하게 되었다.

특이한 점은 30평대나 50평대가 전세가가 거의 차이가 없다는 것. 처음에 7식구(처할머니, 장인/장모, 나/아내, 아들 2)가 살기에 적절한 1층에 위치한 30평대를 보고 맘에 들었는데, 이후 50평대를 보고나서는 다들 마음이 바뀌었다. 관리비야 좀 더 나오겠지만 그 동안 두 집 살림하던 생각하면 큰 차이가 없을 것 같고, 두 집 살림을 합치는 덕분에 살림이 두 배라 딱 맞는 평수로 가게 되면 추후 불편한 점이 많을 것 같았다.

처음에 계약하려던 집은 집주인(?)이 이상해서 막판에 취소. 아버지가 외국 간 딸에게 증여한 아파트인데 딸이 불편해 한다며 대리인 증명을 못해주겠다고 억지를 써서 포기. 나중에 계약이 완료되고 나올 때도 마찬가지일 것 같아서 차라리 잘 되었다고 생각했다. 두 번째 집은 날짜가 안 맞아서 포기할까 하던 찰라 세 번째 집은 집주인이 살고 있어 깨끗하고 전반적으로 맘에 들어서 바로 전세 계약했다.

이 동네는 2001~2002년에 한꺼번에 지어진 터라 집 구조가 거의 비슷하더라. 나중되니까 어지러울 정도. ㅋㅋ

그리고, 현 집주인이 위탁한 쌍용부동산은 아줌마가 별로인 듯. 6년 전에 들어올 때도 맘에 안 들더니 나가는 날짜 맞추는 것도 6주나 남았는데 어렵다고 그러더라. 나중에 어떤 귀찮은 꼬투리를 잡을지 신경 쓰임. 그나마 집주인이 무던한 덕분에 서로 잘 지낸 듯. 그래서 집주인한테는 감사.

상현동

, ,