Media Log

[분류 전체보기]에 해당되는 글 272

  1. h 어썸블로그 안드로이드 앱 2017.02.21
  2. h 재미있는 법률여행 2017.02.20
  3. h 피드백의 속도 2017.02.07
  4. h 네이버캐스트 RSS 피드 공개 (15) 2016.06.09
  5. h 회사원의 가계부 (4) 2016.02.11
  6. h TypeScript, 타입에 대한 고찰 2015.05.05
  7. h 시니어 프로그래머 (2) 2015.02.03
  8. h 매크로는 절대 안돼 by 마츠모토 유키히로 2015.01.12
  9. h Windows Runtime 이야기 (1) 2014.12.05
  10. h 눈물나는 그래프 (2) 2014.08.25
  11. h 한국어로된 stackoverflow.com 을 만드는데 도움을 주세요. 2014.07.06
  12. h 방준영의 블로그 2014.06.06
  13. h 최근에 은행과 병원에서 겪은 이야기 (1) 2014.06.03
  14. h 프로그래머의 5가지 성향 2014.03.15
  15. h 프로그래밍의 첫 번째 규칙: It's Always Your Fault. (1) 2014.03.06
  16. h 개발자를 위한 윈도우즈용 소프트웨어 총 모음. 2013.12.22
  17. h 코딩 호러의 이펙티브 프로그래밍 - 제프 앳우드 (4) 2013.04.08
  18. h 카카오 플레이스와 왓챠를 사랑합니다. 2013.04.07
  19. h 윈도우즈 PE 파일의 구조 2013.03.24
  20. h 스마트 플랫폼 전략 - 황병선 2012.12.24
  21. h 전자책 이야기 (3) 2012.08.20
  22. h 스택오버플로우의 오픈소스? (4) 2012.06.24
  23. h 읽기 좋은 코드가 좋은 코드다 (4) 2012.05.28
  24. h 윈도8에서의 UAC 관련 중요한 변화 2012.05.28
  25. h C++ 카사블랑카 라이브러리 2012.05.02
  26. h 크롬 SSH Client 확장 플러그인 2012.05.02
  27. h 카카오톡 음모론 2012.04.26
  28. h 찰스 펫졸드는 죽지 않았다. Programming Windows 6판 2012.04.24
  29. h Write in C 2012.04.23
  30. h 매크로의 가변인자를 또 다른 매크로로 넘기기 2012.04.16

요즘엔 사람들이 페이스북같은 SNS 에서 정보를 많이 얻어가는 것 같지만, 여전히 블로그는 좋은 정보의 원천지이다.

개발자와 IT 서비스를 하는 사람들을 위해 좋은 글들이 올라오는 블로그들을 모아서 이 글들의 정보를 보여주는 간단한 안드로이드 앱을 친구와 함께 만들었다. 이름은 어썸블로그라고 지었다. (아이폰 앱은 없다.)


https://play.google.com/store/apps/details?id=org.petabytes.awesomeblogs


이런 저런 회사들을 다니면서 특출난 개발자 친구들을 많이 만났지만, 이 앱은 그런 친구들을 위한 앱은 아니다. 실력이 출중한 사람들도 물론 있지만 아직 어디서 정보를 얻어야할지 모르는 소소한 개발자들도 많이 있는 것을 알게되었고 이런 동료들에게 좋은 개발 블로그들을 소개해줌으로써 작은 길잡이가 되었으면 하는 마음이다.


소스코드는 전부 공개되어 있으며, 누구든지 기여 할 수 있다.

https://github.com/BenjaminKim/awesome-blogs (서버)

https://github.com/jungilhan/awesome-blogs-android (안드로이드)

저작자 표시 비영리 동일 조건 변경 허락
신고

'Programming' 카테고리의 다른 글

어썸블로그 안드로이드 앱  (0) 2017.02.21
TypeScript, 타입에 대한 고찰  (0) 2015.05.05
시니어 프로그래머  (2) 2015.02.03
Windows Runtime 이야기  (1) 2014.12.05
눈물나는 그래프  (2) 2014.08.25
방준영의 블로그  (0) 2014.06.06

submit
재미있는 법률여행 1 - 10점
한기찬 지음/김영사

살면서 경제적 혹은 실용적으로 내 삶에 도움을 줬던 고마운 책들을 고르라면, 그동안 읽었던 많은 컴퓨터 책들이 1순위이고, 늦게나마 영어 공부가 하고 싶어 샀던 영어 문법책이 두 번째로 떠오른다.

그리고 오랜 시간이 흘러 마침내 3순위라고 말할 수 있을만한 책을 찾은 것 같다.


법이라는게 이렇게 재미있는 것이었나 싶을 정도로 읽기 쉽게 쓰여졌고, 책 구성도 아주 탄탄하다.

주말 동안 열 시간 정도를 들여서 책을 즐겁게 읽었는데, 다 읽고나서는 다른 사람이 된 것 같은 느낌이 든다. 이 책의 시리즈는 총 5권인데, 나머지 4권도 모두 읽고 싶다.

저작자 표시 비영리 동일 조건 변경 허락
신고

submit

피드백의 속도

2017.02.07 22:38 | 에세이

에어비앤비에는 호스트와 게스트간에 상호 평가를 할 수 있는 평판 시스템이 있는데, 아주 잘 동작하고 있다.


에어비앤비 호스팅을 해오면서 쌓아온 내 점수들을 가만히 바라보다가 커뮤니케이션 부분에서 눈이 멈췄다.

별 5개를 받는 것이 참 어려운 일인데, 어떻게 커뮤니케이션은 약 40여명의 게스트들에게 단 하나도 빠짐없이 별 다섯개를 받을 수 있었을까.



게스트들의 피드백을 받으며 그 답은 빠르게 문의에 답하는 내 `응답속도` 였다는 것을 알게되었다.


커뮤니케이션의 스킬에는 여러가지가 있겠지만, 응답속도는 우리가 쉽게 간과하고 있는 요소는 아닐까.


시중에 판매되는 여러 시간관리 책들이 이메일을 너무 자주보지말라는 조언을 한다. 

메일이나 카톡, 슬랙을 수시로 뒤져보며 이런 지침과는 정반대로 에너지를 비효율적으로 사용하는 내 모습에 불안함도 느끼며 지냈는데, 오늘 이 결과를 보니 꼭 그렇지만도 않다는 기분 좋은 안도감이 든다.

저작자 표시 비영리 동일 조건 변경 허락
신고

'에세이' 카테고리의 다른 글

피드백의 속도  (0) 2017.02.07
회사원의 가계부  (4) 2016.02.11
한국어로된 stackoverflow.com 을 만드는데 도움을 주세요.  (0) 2014.07.06
최근에 은행과 병원에서 겪은 이야기  (1) 2014.06.03
전자책 이야기  (3) 2012.08.20
카카오톡 음모론  (0) 2012.04.26

submit

내가 네이버에서 좋아하는 딱 두가지 제품(혹은 서비스)은 나눔 폰트네이버캐스트이다. 한 5년여 전에 처음 네이버캐스트라는 걸 알았을 때 그 아름답고 잘 쓰여진 글들을 읽으며 홀딱 반해서 더 많은 사람들이 읽었으면 좋겠다 생각했었고, 사람들이 편하게 접근할 수 있도록 네이버에서 RSS 피드를 제공해주면 좋겠다라는 생각도 했었다. 





네이버에서 피드를 제공해주지 않자(네이버는 네이버Me를 쓰라고 권유함. 하지만 누가...) 몇몇 사람들이 직접 크롤링해 피드 서비스를 제공했었는데, 모바일에서 레이아웃이 깨져서 읽기 불편한 서비스도 있고, 잘 쓰고 있다가 어느 날 갑자기 도메인이 사라져버린 서비스도 있었다.


그래서 내가 만들었다.


몇 개월동안 혼자 쓰며 즐거움을 느끼고 있다가 오늘 문득 다른 사람들과도 공유하면 좋을 것 같아서 코드와 함께 피드 주소들을 공개한다.


EDIT: 2016-06-09

새로운 카테고리가 추가되었다는 제보를 받고 리스트를 한번 갱신하였다. 갱신된 최신의 리스트는 https://github.com/BenjaminKim/navercast_rss_feed 에서 볼수 있으며, 아래 리스트에는 추가하지 않았다.


  • 건축 기행(종합) http://navercast.petabytes.org?cid=118

  • 게임의 세계(종합) http://navercast.petabytes.org?cid=2881
  • 공연스테이지(종합) http://navercast.petabytes.org?cid=142
  • 교양 경제학(종합) http://navercast.petabytes.org?cid=89
  • 매일의 디자인(종합) http://navercast.petabytes.org?cid=58
  • 문학 광장(종합) http://navercast.petabytes.org?cid=28
  • 문화유산(종합) http://navercast.petabytes.org?cid=255
  • 미술의 세계(종합) http://navercast.petabytes.org?cid=48
  • 상식백과(종합) http://navercast.petabytes.org?cid=98
  • 스포츠월드(종합) http://navercast.petabytes.org?cid=205
  • 아름다운 한국(종합) http://navercast.petabytes.org?cid=2
  • 옛날신문(종합) http://navercast.petabytes.org?cid=41
  • 오늘의 과학(종합) http://navercast.petabytes.org?cid=18
  • 음식과 요리(종합) http://navercast.petabytes.org?cid=53
  • 음악의 선율(종합) http://navercast.petabytes.org?cid=65
  • 인물과 역사(종합) http://navercast.petabytes.org?cid=74
  • 일상의 심리학(종합) http://navercast.petabytes.org?cid=132
  • 지구촌 산책(종합) http://navercast.petabytes.org?cid=79
  • 철학의 숲(종합) http://navercast.petabytes.org?cid=87
  • 취미의 발견(종합) http://navercast.petabytes.org?cid=179
  • 테크놀로지월드(종합) http://navercast.petabytes.org?cid=204
  • 화제의 인물(종합) http://navercast.petabytes.org?cid=1

  • 저작자 표시 비영리 동일 조건 변경 허락
    신고
    1. Soulbrotha at 2014.12.30 11:08 신고 [edit/del]

      덕분에 좋은 RSS 많이 추가할 수 있었습니다.

      Reply
    2. Favicon of http://novafactory.net BlogIcon Nova at 2014.12.30 11:18 신고 [edit/del]

      잘 보고 갑니다~//

      Reply
    3. seismos at 2015.01.01 19:11 신고 [edit/del]

      유익한 RSS정보 감사합니다. 새해에는 복 많이 받으세요.^^

      Reply
    4. Ethan at 2015.01.03 23:22 신고 [edit/del]

      고맙습니다. 오랫동안 잊고있던 지식인의 서재가 생각나서 검색하다 이렇게 값진 정보를 알게 됐네요. 새해 복 많이 받으세요~~

      Reply
    5. ban at 2015.01.11 00:40 신고 [edit/del]

      감사합니다. 무엇보다도 고생하신걸 공유하시는 마음이 감사합니다.

      Reply
    6. asd at 2015.01.20 16:30 신고 [edit/del]

      유용한 정보 고맙습니다. 2015년 한해 즐거운 일 가득하시길.

      Reply
    7. sj at 2015.01.21 05:18 신고 [edit/del]

      감사합니다!

      Reply
    8. thankyou:) at 2015.03.12 14:40 신고 [edit/del]

      찾고 있었는데 감사합니다~

      Reply
    9. sang at 2015.04.09 16:15 신고 [edit/del]

      정보공개해주셔서 많은 도움이 될것 같습니다.

      Reply
    10. koo at 2015.07.15 15:27 신고 [edit/del]

      와우.. 정말 감사드립니다. 덕분에 아주 많은 도움 받았습니다.

      Reply
    11. npower at 2015.07.23 21:50 신고 [edit/del]

      좋은 정보 감사합니다!!

      Reply
    12. butumm at 2016.06.09 04:44 신고 [edit/del]

      제가 찾던 바로 그 피드들입니다. 잘 쓰겠습니다. 너무 감사합니다!!
      그리고,
      아직 네이버캐스트 즐겨보시는지 모르겠으나, "인문과 과학의 만남"이라는 섹션이 추가되었습니다.
      (http://navercast.naver.com/list.nhn?cid=2911&category_id=2911)
      최근에 추가되어 그런지 올려주신 리스트에는 포함되지 않은데요.
      올려주신 피드 주소들을 응용해서 주소 뒤의 아이디 넘버만 2911로 수정해서 추가하니 일단 해당 피드가 추가되긴했습니다.
      (http://navercast.petabytes.org/?cid=2911)
      그런데 전체 목록이 아니라 딱 세 개만 추가되고 마는데요. 혹시 문제가 뭔지 잠깐 봐주실 수 있으신가요?
      고맙습니다.

      Reply
      • Favicon of http://www.benjaminlog.com BlogIcon 김재호 at 2016.06.09 10:48 신고 [edit/del]

        제보해 주셔서 감사드립니다.
        https://github.com/BenjaminKim/navercast_rss_feed 페이지에 신규로 추가된 내용도 모두 적용해두었으니 한번 확인해보시기 바랍니다.

        3개만 추가되는 이유는 트래픽이 점점 많아짐에 따라 개인서버 비용을 줄이기 위해서 최근 3개 글만 보내주도록 만들었기 때문이에요. 더 개선할 수 있을지 방법을 고민해보겠습니다.

        저도 덕분에 재밌는 주제들 더 등록해서 볼수 있게 되었네요. 고맙습니다.

    13. ㅇㅅㅇ at 2016.11.12 16:43 신고 [edit/del]

      감사합니다^^

      Reply

    submit

    회사원의 가계부

    2016.02.11 00:06 | 에세이

    많은 사람들이 자신이 한 달에 얼마를 쓰는지 잘 모르고 있으며, 실제로 쓴 돈보다 더 적게 쓸 것이라고 추정하고 있는 것을 봐왔다.

    왜 이렇게 낙관적인 생각을 갖게 되는 것인지는 잘 모르겠지만, 나 역시도 그랬었다.

    우연한 기회에 별 생각없이 가계부나 써볼까 했었는데, 한 달 뒤 내가 실제로 쓰는 돈이 추정치와 꽤 많이 벗어난다는 것을 깨달아 가는 과정이(물론 내 예상보다 더 많이 돈을 쓰고 있어서) 고통스러웠던 기억이 난다.


    이런 일이 어쩌면 일을 할 때도 있지 않나 하는 생각이 든다.

    사람들은 자신이 (다른 사람들이 자신을 평가해주는 것보다) 일을 잘하는 편이라고 낙관적으로 생각을 하는 것 같다. 평가시기에 돌아오는 피드백에 대한 반발, 연봉에 대한 불만 등은 어쩌면 이런 낙관적인 생각들 때문에 나타나는 현상은 아닌지 모르겠다.


    가계부를 쓰기로 결정한 이후로 가장 좋은 점은 내 상태를 내가 정확히 알게 되었다는 점이다.

    2010년쯤에는 얼마를 벌었고 얼마를 썼는지, 그에 비해 지금은 한달에 얼마를 쓰고 있는지를 잘 파악하고 있다.(지출이 엄청나게 늘었다;;)


    위에 가계부를 처음 썼을 때 고통스러웠다고 표현했는데, 그 고통이란 바로 이런 느낌이었다.

    "내가 상위 10% 정도에는 들 정도로 절약 정신이 투철하고 실제로도 그렇다고 생각했는데, 뚜껑을 열어보니 그게 전혀 아니었어."


    '일' 에 대한 가계부를 쓴다고 하면 아마 이런 느낌을 받을 수 있을 것 같다.

    "나는 야근도 다른 사람들보다 많이 하고 회사에서 상위 10% 에는 들 정도로 많은 기여를 하고 있다고 생각했는데, 지금까지 한 일들을 쭉 펼쳐보니 실제로는 그냥 평균밖에 못하는 사람이었어.(이런, 심지어는 야근도 별로 안했네)"


    어렴풋이 생각해보는 것과 사실은 다를 수 있다. 나는 이런 판단 착오가 위에서 말한 고통보다 더 무섭기 때문에, 우선 내가 회사에서 하는 모든 일들을 가계부를 쓰듯이 구체적으로 기록해보기로 했다.

    오늘은 어떤 코드를 짰고, 어떤 문제에 대해서 고민을 했고 이것은 어떤 방식으로 해결했는지.

    고민만 하다가 결국 문제를 못풀고 포기한 것은 아닌지. 포기했으면 포기했다고 기록.

    지각을 했으면 지각을 했다고 기록하고, 낮잠 잔 날은 낮잠 잔 것도 기록한다.

    가계부를 쓸 때도 수입만 적고 지출을 빼놓을 수는 없듯이, 일을 할 때도 잘한 일과 못한 일을 다 기록 하는 것이 중요하다.


    이런 과정이 예전의 나보다 더 나아지게 도움을 주었는지는 확신할 수 없지만(조금은 주었다고 생각은 한다) 적어도 내 상태가 어느 수준인지는 잘 알게 해준 것은 맞는 것 같다.


    최근에는 매일 하는 일의 기록 외에도, 내가 1년에 통상 몇개 정도 커밋을 하는지, 몇 권의 책을 읽는지를 관심있게 관찰하고 기록하면서 그 숫자를 외우고 있으며, 이런 것들을 나 자신을 평가할 때 쓰는 요소 중 하나로 삼기도 한다. 이런 가계부의 요소들은 자신이 어떤 일을 하고 있는지에 따라 달라질 수 있을 것 같다.


    만약 일을 하면서 자신이 과소평가 받고 있다고 느끼는 사람들이 있다면, 먼저 자신만의 가계부를 한번 만들어서 기록해보면 어떨까? 어떤 식으로든 도움이 될 것이라 생각한다.



    저작자 표시 비영리 동일 조건 변경 허락
    신고

    '에세이' 카테고리의 다른 글

    피드백의 속도  (0) 2017.02.07
    회사원의 가계부  (4) 2016.02.11
    한국어로된 stackoverflow.com 을 만드는데 도움을 주세요.  (0) 2014.07.06
    최근에 은행과 병원에서 겪은 이야기  (1) 2014.06.03
    전자책 이야기  (3) 2012.08.20
    카카오톡 음모론  (0) 2012.04.26
    1. Favicon of http://lastwave.tistory.com BlogIcon Lastwave at 2016.02.11 12:12 신고 [edit/del]

      저는 가계부는 아니지만 월 초에 이전 달의 총 지출을 정리해보는 습관을 언제부터인가 들였는데
      예상했던 것보다 카드를 습관처럼 많이 사용하고 있더라구요.

      Reply
    2. Favicon of http://blog.naver.com/xellmi BlogIcon 민대원 at 2016.05.26 15:23 신고 [edit/del]

      안녕하세요.
      sms 카드 파싱 관련된 자료를 찾아보다가 ruby로 개발하신 credit-card-sms-parser 보게 되었습니다.
      자바로 개발한 안드로이드 어플리케이션에서는 credit-card-sms-parser 사용할 수 있는 방법이 있나요?

      ruby에 대해서 아는게 없어서 java를 지원해주는 jruby와 안드로이드 개발 할 수 있는 ruboto에 대해서 알아보는 있는 중인데 이 방법이 맞는건지 궁금해서 질문드립니다..


      Reply
      • Favicon of http://www.benjaminlog.com BlogIcon 김재호 at 2016.05.26 17:19 신고 [edit/del]

        Ruby 코드를 사용하는 것 보다 Java 로 직접 만드시는게 더 좋은 방법으로 생각됩니다.
        https://github.com/sng2c/RuntimeLexer/blob/master/src/test/java/com/mabook/java/runtimelexer/application/KoreaBankSmsParserTest.java
        여기 코드를 참고로 시작해보시면 좋을 듯 합니다. ^^

    3. BlogIcon 민대원 at 2016.05.26 18:06 신고 [edit/del]

      와 정말 답변감사드립니다.
      우선 Java로 개발해보고 Ruby 코드도 이용하는 방법도 시도해봐야겠습니다..

      Reply

    submit

    쉬는 날을 틈타 Build 2015 동영상을 다운 받아서 하나씩 보는 중이다. Async/Await 이라는 부제에 끌려서 들어갔는데, 이 제목은 낚시였고 TypeScript 에 대한 설명이 주를 이룬다.

    TypeScript 자체에는 큰 관심이 없지만, 앤더스 헤일스벅이 타입이라는 것에 대해 그동안 고민해온 고찰을 들어볼 수 있었고 또 전설의 레전드가 직접 코딩하는 것을 구경하는 것만으로도 무척 즐겁게 봤다.


    동영상은 아래 링크에서 볼 수 있다.

    https://channel9.msdn.com/Events/Build/2015/3-644



    저작자 표시 비영리 동일 조건 변경 허락
    신고

    'Programming' 카테고리의 다른 글

    어썸블로그 안드로이드 앱  (0) 2017.02.21
    TypeScript, 타입에 대한 고찰  (0) 2015.05.05
    시니어 프로그래머  (2) 2015.02.03
    Windows Runtime 이야기  (1) 2014.12.05
    눈물나는 그래프  (2) 2014.08.25
    방준영의 블로그  (0) 2014.06.06

    submit

    보통 우리 나라 IT회사들의 평균 나이는 31-33세 인데 내 나이가 이제 우리 나이로 35살이니 평균 보다 조금 늙은(?) 나이인 것 같다.

    그래서인지 모르겠지만 언제부터인가 회사에서 가끔씩 나를 시니어라고 부를 때가(분류할 때가) 있는데, 나는 그럴 때마다 몸에 소름이 돋는다. 소름이 돋는다는 것은 좋은 쪽이 아니라 나쁜 의미의 표현으로 사용한 것인데, 그것은 내가 시니어라는 단어에 특별한 의미를 부여하고 있기 때문인 것 같다.


    내가 이전에 윈도 프로그래밍을 공부할 때 너무 좋아하고 닮고 싶던 프로그래머들이 몇 명 있었는데, 그 중 두 명은 Hans PassantRaymond Chen 이라는 사람이었다.

    Hans 는 스택오버플로우에서 놀면서 알게된 사람이고 스택오버플로우의 전체 랭킹 10위 안에 들 정도로 실력있는 사람이다. 레이몬드는 The Old New Thing 이란 블로그로 오래 전부터 유명했던 마이크로소프트의 해커이다.

    3년 전까지만 해도 아침에 눈뜨고 저녁에 잠들기 전에는 항상 그들이 스택오버플로우와 블로그에 쓴 글들을 받아서 읽어보며 배우고 기뻐했던 기억이 난다. (둘 다 로우레벨 프로그래밍부터 하이레벨 프로그래밍 까지 분야을 막론하고 탁월함을 드러내기도 했고 시니컬 하고 톡톡 쏘아 말하는 말투까지 너무 비슷해서 나는 어쩌면 이 둘이 같은 사람이 아닐까 생각한 적도 있었다.)


    어쨌든.

    Software Architect 이든 Chief Technical Officer 든 온갖 멋진 수식어를 가져다 붙여도 이상할 것 같지 않은 이 두 사람들. 그 중 Hans Passant 는 LinkedIn 에 자신을 Sony 의 Senior Programmer 라고 소개해놓았다.

    Raymond 는 언젠가 블로그에 자기가 Senior Engineer 라고 자랑스러워하는 어떤 얼간이를 비꼬는 글을 쓰기도 했었는데, 이런 것들을 보면서 아마 나는 저 두 사람에게 영향을 받은 것이 확실한 것 같다.


    그래서 그런지 나는 시니어 프로그래머라는 단어을 보면 저 두사람이 머리 속에 탁 떠오른다. 누군가 나를 시니어 프로그래머로 부르거나 자신을 시니어 프로그래머라고 호칭하고 다니는 사람들을 보면 우리가 시니어 라는 말을 너무 함부로 사용하고 있는 것은 아닐까 하는 생각을 한다.

    저작자 표시 비영리 동일 조건 변경 허락
    신고

    'Programming' 카테고리의 다른 글

    어썸블로그 안드로이드 앱  (0) 2017.02.21
    TypeScript, 타입에 대한 고찰  (0) 2015.05.05
    시니어 프로그래머  (2) 2015.02.03
    Windows Runtime 이야기  (1) 2014.12.05
    눈물나는 그래프  (2) 2014.08.25
    방준영의 블로그  (0) 2014.06.06
    1. 서우석 at 2015.10.16 01:39 신고 [edit/del]

      저도 존경하는 Raymond가 전에 Senior engineer 비꼬는 글을 저도 봐서 스스로에게 시니어 엔지니어라는 말을 하기가 꺼려지더라구요. 잘 지내시죠? :-)

      Reply
      • Favicon of http://www.benjaminlog.com BlogIcon 김재호 at 2015.10.28 18:04 신고 [edit/del]

        네 잘지내고 있습니다. 요즘에는 시니어 해커는 커녕 그냥 회사원이 되가는 것 같네요. 초심을 잃지 말고 열심히 해야하는데 말이죠.

    submit



    2014 RubyConf 에서 마츠와의 질문 답변 시간에 어떤 청중 하나가 루비에 매크로를 지원할 생각이 있냐고 질문하자,


    My short answer is NO.

    A slightly longer answer is...NO WAY! (청중들 폭소)


    마츠는 C언어의 매크로를 생각하고 대답한 것이 틀림없는데(나를 포함한 웃은 사람들도), 마츠의 대답을 듣고 아무말 없이 돌아서서 뒤로 나가던 그 질문자도 그런 의도였는지는 지금 다시 생각해보면 확실하지가 않다.


    저작자 표시 비영리 동일 조건 변경 허락
    신고

    submit

    꽤 오랫동안 윈도 프로그래밍에서 떨어져 살다가 윈도폰은 어떨지 궁금해서 문득 윈도폰 하나를 중고로 구입해본 적이 있었다. 그게 NT 커널이 올라가있는 윈도폰 8.0 이었었고, 세컨드 폰으로 장난감 다루듯이 사용해보다가 시간이 좀 흐르고 BUILD 2014 행사에서 MS가 윈도폰 8.1을 발표했다.


    그 때쯤 처음으로 윈도폰과 Windows Runtime 에 관심을 가지고 진지하게 책을 읽어보기 시작했으며, 역시 처음으로 Build 2014 에 나오는 대부분의 비디오를 다운받아서 봤는데(기존에는 키노트만 봤었다) Windows Rumtime 기반으로 한번 앱을 만들어보는 것도 좋겠다는 생각이 들었다.

    마침 회사에서는 윈도폰을 위한 카카오톡을 새로 만들기로 결정을 했기 때문에, 나도 꼽사리를 껴서 같이 만들어 보기로 했다.


    오래 전에는 윈도 개발에 익숙했기도 하고 이것저것 아는 것들도 조금 있었기 때문에 처음에는 재밌고 그리 오래 걸리지 않을 작업이라고 쉽게 생각했었는데 막상 Windows Runtime 과 부딪혀보고는 곧 그렇게 쉬운 일이 아니라는 것을 깨달았다. 기존에 알고 있었던 네이티브 지식들과 Win32 Api 지식들은 거의 도움이 되지 않았고, Windows Rumtime 의 새로운 프로세스, 패키지 데이터, 네비게이션 모델 등을 다 새로 공부해야만 했다. 닷넷은 책으로만 보고 작은 프로그램들 정도만 작성해봤었는데, 처음으로 정교한 프로젝트에 맞딱드려보니 UI 와 데이터를 유지보수하기 쉽게 바인딩하는게 생각처럼 쉽지 않아 고생을 많이 했었고 또 Task 기반 프로그래밍 역시 책으로 이해한 것과는 달리 실제로 적용해보면서 꽤 많이 해맸었던 것 같다. 대부분의 라이브러리들이 윈도폰용의 Windows Runtime 을 지원하지 않거나 지원 준비중이 었기 때문에 스트레스를 받기도 했다.


    무엇보다 나를 괴롭혔던 것은 Windows Runtime 이라는 새로운 환경 자체였는데, 아무리 책을 보고, MSDN 을 보고 잘 이해했다고 생각을 하고 코드를 짜도 전혀 기대하지 않은 동작을 해서 미궁에 빠졌을 때가 여러번 있었다. 새로운 환경에 부딪히면서 일을 할 때 이렇게 미궁에 빠지게 되는 때의 원인은 다음과 같은 경우들이 있는 것 같다.


    1. 프로그래머 자신은 잘 이해했다고 생각했지만 실제로는 잘 이해하지 못하고 있었다.

    2. 문서에 정보가 애매하거나 빈약하게 써있어서 이해하기가 쉽지 않았거나 혹은 문서에 정보가 적혀있지 않았다.

    3. 기반 프레임워크에 버그가 있었다.


    나는 대부분의 문제는 1번에서 발생한다고 생각하는(사실은 거의 확신) 편인데, 이번 프로젝트에서는 2번과 3번의 문제가 더 많았던 것 같다. 정보를 얻을 수 있는 곳이 없어서 정말 많은 실험과 해킹을 하면서 답을 알아낸 경우가 많이 있었고, 윈도폰 자체의 버그 때문에 Windows Phone 8.1 Update 1이 나오고 나서 자연스레 해결된 문제들도 있었다. 어떤 문제는 아직도 해결되지 않아 Windows 10 에서나 해결될 수 있을 거라는 답변도 받았다.

    예전에 Win32 Api 들을 다룰 때는 MSDN 이 정말 좋은 정보들이 많은 문서시스템이라는 생각을 했었는데, 닷넷 쪽과 Windows Runtime Api 문서들을 보면서 생각이 좀 바뀌었다. 파이썬이나 루비 온 레일즈와 같은 오픈소스 언어/프레임워크 들의 문서화가 훨씬 더 잘되어 있는 것 같다. Windows Runtime 용 샘플 코드들 또한 매우 조잡한 수준이었다.


    그럼에도 불구하고 (수많은 삽질로 인해 시스템에 익숙함을 갖게된 상태에서 바라보면) 기존의 Win32 프로그래밍 환경과 비교했을 때, 프로그래밍이 많이 쉬워진 것은 같다. 닷넷의 풍부한 모든 기능들을 사용할 수 있고, 레이아웃을 다루는 일과 스케일링 처리도 훨씬 쉬워졌다. 클라이언트 프로그램을 작성할 때는 UI를 멈추지 않게 작성하는 것이 아주 중요한데, C#의 Task 기반 프로그래밍과 Windows Runtime의 Api 들은 이를 쉽게 가능하게 만들어주는 것도 좋은 점 중의 하나였다.


    이런 저런 고생들을 하며 지난 달에 Windows Rumtime 으로 완전히 새롭게 태어난 카카오톡을 오픈하고 애프터 서비스를 좀 하다가 얼마 전 다시 서버팀으로 돌아왔다. 이제 윈도우즈로 개발 할 일이 또 거의 없어져서 집에서 사용하던 랩탑은 Windows 10 으로 새로 설치해버리고 새 운영체제를 조금씩 알아가고 있는 중이다. API 가 어떻게 바뀌었는지는 아직 잘 모르겠지만 사용자 입장에서 봤을 때, 모던앱들이 창크기가 변경 가능하다는 점은 정말 편리한 것 같고, 이제서야 뭔가를 모던앱을 만들어보는 것도 좋겠다 하는 생각이 처음으로 든다.


    두줄 요약:

    1. Windows Runtime 은 조금 더 개선되고 다듬어질 필요가 있다.

    2. 만약 모던앱 혹은 윈도폰 앱 개발에 흥미를 느끼고 있다면 Windows 10 Developer Preview 정도는 나온 뒤에 공부를 시작하는 것을 추천한다. 안 그러면 고생만 한다.

    저작자 표시 비영리 동일 조건 변경 허락
    신고

    'Programming' 카테고리의 다른 글

    TypeScript, 타입에 대한 고찰  (0) 2015.05.05
    시니어 프로그래머  (2) 2015.02.03
    Windows Runtime 이야기  (1) 2014.12.05
    눈물나는 그래프  (2) 2014.08.25
    방준영의 블로그  (0) 2014.06.06
    프로그래머의 5가지 성향  (0) 2014.03.15
    1. 송병학 at 2014.12.05 08:57 신고 [edit/del]

      서버 개발하시면서 윈도우폰까지 하시고 부지런하시네요. 좋은 글 감사합니다 ^^

      Reply

    submit

    눈물나는 그래프

    2014.08.25 22:24 | Programming


    예전에 존 레식의 매일 매일 코딩하기라는 글을 본 기억이 문득 떠올라서 나도 내 Github 그래프를 한번 열어봤다.

    8년이 되는 경력 동안 꾸준히 저 정도 그래프를 그린 것 같은데 기대만큼 실력은 늘지 않는 것 같다.

    존 레식 같은 해커가 되려면 몇 년이나 이렇게 살아야 하는 걸까. 그래서 눈물나는 그래프.


    저작자 표시 비영리 동일 조건 변경 허락
    신고

    'Programming' 카테고리의 다른 글

    시니어 프로그래머  (2) 2015.02.03
    Windows Runtime 이야기  (1) 2014.12.05
    눈물나는 그래프  (2) 2014.08.25
    방준영의 블로그  (0) 2014.06.06
    프로그래머의 5가지 성향  (0) 2014.03.15
    프로그래밍의 첫 번째 규칙: It's Always Your Fault.  (1) 2014.03.06
    1. 서우석 at 2015.10.16 01:42 신고 [edit/del]

      와 엄청나게 많은 commit이네요. 항상 응원합니다!

      Reply

    submit

    Area51 이라는 곳은 스택오버플로를 만드는 사람들에게 "이런 주제의 또 다른 질문/답변 사이트를 만들어주세요!" 라고 제안을 할수 있는 공식적인 장소이다. 그리고 이러한 제안을 수락하는 방식 또한 여러 사람들의 집단 의견을 따른다. 즉, 많은 사람들이 참여하고, 재밌고 좋다고 박수쳐줘야 승인된다.


    최근 몇몇 사람들이 한국어 스택오버플로우의 제안을 통과시키기 위해 노력을 하고 있는 것을 우연히 보고도 작은 도움이나마 주고 싶어서 글을 적어본다.


    제안이 완전히 통과되기 위해서는 defined 단계와 commit 그리고 beta 단계를 거쳐야 하는데, 현재 한국어 스택오버플로는 defined 단계가 완성되기 직전이다.(현재 적혀진 질문들에 대해서 약간의 upvote 만 더 있으면 된다. 10점 이상의 upvote 를 받은 질문이 40개가 필요하다.)


    현재, 영어 말고 다른언어로 스택오버플로 서비스가 제공되고 있는 것은 포르투갈어 뿐인 것으로 보이는데, 한국어도 충분히 가능성이 있다고 본다. 많이들 공유해주고 참여해주어서 좋은 한글 개발자 사이트가 생겼으면 좋겠다.


    아래 링크에 도움 줄 수 있는 방법이 적혀있다. 쉽다.

    https://github.com/so-in-korean/sok/wiki/How-to-Contribute

    저작자 표시 비영리 동일 조건 변경 허락
    신고

    '에세이' 카테고리의 다른 글

    피드백의 속도  (0) 2017.02.07
    회사원의 가계부  (4) 2016.02.11
    한국어로된 stackoverflow.com 을 만드는데 도움을 주세요.  (0) 2014.07.06
    최근에 은행과 병원에서 겪은 이야기  (1) 2014.06.03
    전자책 이야기  (3) 2012.08.20
    카카오톡 음모론  (0) 2012.04.26

    submit

    방준영의 블로그

    2014.06.06 14:09 | Programming

    내가 좋아하는 국내 프로그래밍 블로그들에서 살짝 언급했던 방준영의 블로그가 다시 돌아왔다.

    최근에는 국내 프로그래밍 블로그들이 거의 전멸 하다시피 해서 해커뉴스만 울며 겨자먹기로 보면서(왜냐면 영어를 잘 못하기 때문에) 삶을 살아가고 있었는데, 이런 좋은 블로그가 돌아와줘서 정말 기쁘다.

    이번에는 중간에 잠적(?)하지 않고 꾸준히 좋은 글들을 많이 써줘서 더 많은 사람들이 그의 블로그를 찾고, 나처럼 즐거움을 느꼈으면 좋겠다.

    저작자 표시 비영리 동일 조건 변경 허락
    신고

    'Programming' 카테고리의 다른 글

    Windows Runtime 이야기  (1) 2014.12.05
    눈물나는 그래프  (2) 2014.08.25
    방준영의 블로그  (0) 2014.06.06
    프로그래머의 5가지 성향  (0) 2014.03.15
    프로그래밍의 첫 번째 규칙: It's Always Your Fault.  (1) 2014.03.06
    윈도우즈 PE 파일의 구조  (0) 2013.03.24

    submit

    1. 마이너스 통장의 한도를 조금 더 늘려두어야겠다는 생각이 들어 은행을 찾아갔다. 15분여를 기다리고 차례가 되어 창구에 앉았는데, 신분증을 내밀고 거의 10초만에 ‘정말 죄송하지만, 우리 지점에서는 처리할 수가 없고 원래 대출을 받으셨던 지점에 가셔야 처리가 가능합니다.’ 라는 대답이 나왔다. 이유를 가르쳐달라고 물어봤더니, 

     “같은 은행이긴 하지만 지점들 간에도 거래 실적이라는 것이 있고, 다른 지점의 실적을 뺏어오는 일이 되기 때문이니 양해를 부탁드립니다.” 라는 것이다. 얼핏 들으면 고개가 끄덕여질 지도 모르겠지만 잘 생각해보면 웃기는 소리이다. 지점간에 실적 다툼으로 고객의 편의는 전혀 고려하고 있지 않으니 말이다.

    항의하거나 설득해도 나만 스트레스 받을 것 같아서 예 알겠습니다 하고는 회사 근처에 있는 원래 대출을 받았던 은행을 찾아가서 심사를 받느라 창구에 앉아 대기하고 있었는데 또 재밌는 일이 일어났다.

    직원 하나가 전화통화를 끊더니 창구 뒷자리에 앉은 높은(?) 상사에게 보고를 하는 모습이 보였는데, 통화를 한 고객이 임대차 계약서를 보내주기는 싫고 딱 필요한 정보만 주고 싶다고 했다보다. 그 말을 들은 상사가 “아이고, 가지가지한다 진짜. 뭘 그리 비밀이많아. 쯧쯧.” 하면서 혀를 끌끌 차는 것이다. 창구에 앉아있던 사람들은 다 그 소리를 들을 수 있었는데 그런 모습을 보고 있자니 직원들이 고객을 도대체 어떻게 생각하고 있는지가 궁금해졌다.


    2. 최근에 가족들이 아파서 병원을 몇번 왔다갔다 하게 되었다.

    주말이고 재밌는 TV 프로들이 하고 있는 시간이라 병실에 있는 사람들이 다들 TV를 보고 쉬고 있었는데, 나이가 지긋해보이는 한 의사가 젊은 친구 둘과 함께 옆 침대에 있던 환자의 회진을 들어왔다.

    나는 티비에 관심이 없어서 무슨 이야기를 하나 유심히 바라보고 있었는데, 마치 군대마냥 열중쉬어를 하고 있던 젊은 친구 둘 중 하나가 의사가 말하고 있는데 TV 소리가 거슬린다고 생각했는지 성큼성큼 걸어가서 사람들의 의견을 물어보지도 않고 TV를 툭 꺼버리고는 다시 돌아가 열중쉬어 자세를 취하는 것이 아닌가.

    별 알맹이 없는 회진 대화가 끝나고 그 삼인방은 TV를 다시 켜주지도 않은채 그냥 나가버렸다.


    한줄 요약: 병원이든 은행이든 제발 제대로된 회사가 나타나서 이런 늙어빠진 회사들은 하루 빨리 다 망해버렸으면 좋겠다.

    저작자 표시 비영리 동일 조건 변경 허락
    신고

    '에세이' 카테고리의 다른 글

    회사원의 가계부  (4) 2016.02.11
    한국어로된 stackoverflow.com 을 만드는데 도움을 주세요.  (0) 2014.07.06
    최근에 은행과 병원에서 겪은 이야기  (1) 2014.06.03
    전자책 이야기  (3) 2012.08.20
    카카오톡 음모론  (0) 2012.04.26
    Write in C  (0) 2012.04.23
    1. BlogIcon 어군 at 2014.06.11 14:52 신고 [edit/del]

      어느 은행 병원인지....쯔쯔

      Reply

    submit


    1. 쉬운 문제를 어렵다고 말하며 매번 포기하는 사람.
    2. 어려운 문제를 쉽다고 말하며 틀린 답을 내는 사람.
    3. 어려운 문제를 쉽다고 말하며 쉬운 솔루션으로 그저 그런 답을 내는 사람.
    4. 어려운 문제를 어렵다고 말하며 제대로 된 솔루션을 만들어내는 사람.
    5. 어려운 문제를 쉽다고 말하며 제대로 된 솔루션을 만들어내는 사람.

    1,2,3 번은 많이 봤는데 4번은 몇 명 만나보지 못한 것 같다. 5번은 아직까진 한 명도 보지 못했다.


    저작자 표시 비영리 동일 조건 변경 허락
    신고

    submit

    여러분은 이게 어떤 기분인지 알 것입니다. 이는 우리 모두가 한번쯤 겪었던 일입니다. 여러분은 코드를 수십 번 읽어 보았으나 여전히 무엇이 문제인지 발견하지 못하고 있습니다. 하지만 그 코드에는 여러분이 도저히 처리할 수 없는 버그 혹은 오류가 존재하고 있습니다. 여러분은 코딩하고 있는 컴퓨터에 문제가 있거나 프로그램을 실행하는 운영체제, 혹은 사용하는 도구나 라이브러리에 문제가 있다고 생각해버립니다.


    “분명히 그럴꺼야!”


    하지만 아무리 좌절스럽더라도 그런 접근을 해서는 안됩니다. 우연에 맡기는 프로그래밍은 이제 그만하십시오. 그건 정말 나쁜 행동입니다. 어렵고 모호한 버그와 맞서는 것이 좌절감을 줄 수도 있지만, 그런 좌절감 때문에 잘못된 길로 들어서서는 안됩니다.


    좋은 프로그래머가 되기 위한 필수 조건은 여러분이 작성한 코드에 문제가 있을 때마다 그것이 항상 자신의 잘못이라고 생각하는 일입니다. 이 내용은 실용주의 프로그래머에서 ‘select 함수는 잘못되지 않았다’ 부분에 잘 요약되어 있습니다:


    대부분의 프로젝트에서 당신이 디버깅하고 있는 코드는 당신의 프로젝트 팀, 써드파티 결과물(데이터베이스, 네트워킹, 그래픽 라이브러리, 특화된 통신 방법들이나 알고리즘 등), 플랫폼 환경 상에서(운영체제, 시스템 라이브러리, 컴파일러) 당신과 다른 이들에 의해 작성된 응용 프로그램 코드의 결합물일 것이다.

    운영체제나 컴파일러 혹은 써드파티 제품에 버그가 있을 수도 있다. 하지만 그것이 첫 번째로 의심하는 사항이 되어서는 안된다. 당신의 코드에 버그가 존재할 가능성이 훨씬 더 크다. 라이브러리 자체에 버그가 있다고 의심하는 것보다는 라이브러리를 호출하는 응용 프로그램의 코드가 문제가 있다고 생각하는 것이 보통 더 이득이다. 설사 써드 파티 코드에 문제가 있었다 할지라도, 어짜피 버그리포트를 제출하기 전에 자신의 코드를 제거하는 일을 해야만 한다.

    우리는 한 프로젝트에서 솔라리스 운영체제에 있는 select 시스템 함수에 버그가 있다고 확신하는 한 고참 개발자와 일한 적이 있었다. 어떤 설득이나 논리도 그의 생각을 바꿀 수는 없었다. (같은 컴퓨터에서 다른 네트워크 프로그램들은 모두 잘 작동했지만 그건 그에게 별 상관이 없었다.)

    그는 몇 주동안 문제를 해결하려고 이리저리 코드를 변경해보았지만, 이상하게도 그 문제는 해결이 되지 않는 것처럼 보였다. 그가 우리의 강요에 의해 억지로 자리에 앉아 select함수의 문서를 읽었을 때, 그제서야 그는 어떤 것이 문제였는지 깨달았고 그 문제를 몇 분만에 해결했다. 그 이후 우리는 누군가가 자신의 실수일 수 있는 문제를 시스템의 버그라고 탓하는 것을 볼 때마다 “select 함수의 버그” 라는 말을 사용하게 되었다.


    코드 주인의식의 다른 말은 코드 책임의식입니다. 여러분의 소프트웨어의 문제가 무엇이던지 간에 -그 문제가 자신의 코드에 없었다 할지라도- 항상 자신의 코드안에 문제가 있다고 가정해야 하고 그에 따라 행동해야 합니다. 만약 여러분의 소프트웨어가 최고가 되길 원한다면 제품의 버그에 대해 전적으로 책임을 져야만 합니다. 사실 엄밀히 말하면 그럴 필요까지는 없습니다. 다만 이것이 여러분이 존경과 신뢰를 얻게 되는 방법입니다. 만약 그 문제에 대해 다른 사람들, 회사나 다른 소스로 그 잘못을 떠넘긴다면 여러분은 분명 존경과 신뢰를 얻지 못하게 될 것입니다.


    여러분도 알다시피, 오류가 여러분의 잘못이 아닌 소프트웨어의 오류일 확률은 통계적으로 극히 드뭅니다. 스티브 맥코넬은 그의 책 코드 컴플리트에서 이 사실을 증명하는 두 가지 연구사례를 인용했습니다:


    1973년과 1984년에 수행된 연구는 보고된 총 버그의 약 95%가 프로그래머에 의해서 발생한 것들이라는 것을 발견했다. 2%는 시스템 소프트웨어(컴파일러나 운영체제) 이고 2%는 그 외의 다른 소프트웨어들이었으며 1%는 하드웨어였다. 오늘날 시스템 소프트웨어와 개발도구들은 1970~80년대에 비해서 훨씬 많은 사람들에 의해 사용되어지고 있기 때문에 지금은 프로그래머의 오류 비율이 예전보다 더 높아졌을 것이라 추측한다.


    여러분의 소프트웨어가 가지고 있는 문제가 무엇이든지간에 주인의식을 가지시기 바랍니다. 먼저 여러분의 코드에서부터 출발해서, 그 문제 원인에 대한 결정적 증거를 손에 넣을 때까지 계속해서 바깥으로 범위를 넓혀가며 살펴보십시오. 만약 그 문제가 자신이 컨트롤 할 수 없는 다른 코드에 존재한다면 문제 진단 및 디버깅 기술을 배워야 할 뿐만 아니라 자신의 주장을 뒷받침 해줄 수 있는 증거 또한 확보해 두어야 할 것입니다.


    이 과정은 어깨를 한번 으쓱하며 운영체제, 개발도구, 프레임워크의 잘못으로 돌리는 것 보다는 훨씬 더 번거로운 일입니다. 그러나 이는 여러분에게 남 탓으로 돌리기나 문제 회피 등으로는 절대로 얻지 못하는 신뢰와 존경을 얻도록 할 것입니다.


    만일 진심으로 좋은 프로그래머가 되고 싶다면 “그건 내 실수야. 내가 그 원인이 뭔지 찾아내고 말거야.” 라고 말하는 것을 꺼리지 마십시오.


    이 글은 스택오버플로우를 개발한 제프 앳우드가 2008년 3월에 쓴 The First Rule of Programming: It’s Always Your Fault 를 원저자의 허락을 받고 번역한 글입니다.


    --

    2년여 전 즈음에, 카카오의 동료들하고 심심풀이로 기술 관련 좋은 글들을 구글 독스에서 소셜 번역(?) 을 하곤 했었는데, 그 중 하나였던 이 글이 최근 자꾸 생각나서 다시 읽어보다가 블로그에 올려야지 생각하게 되었다.(Jenny, Clare, Probe 감사!)

    이 글은 코딩 호러의 이펙티브 프로그래밍이라는 번역서 내에도 담겨있으며, 이 책에는 다른 좋은 글들도 많으니 관심이 있는 사람들은 읽어보는 것도 좋겠다. 제프 앳우드의 다른 책으로는 코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기라는 책도 있다. 둘 다 너무 재미있고 좋은 이야기들이 많이 담겨있는 책이다.

    저작자 표시 비영리 동일 조건 변경 허락
    신고
    1. 재호님팬 at 2014.04.01 22:07 신고 [edit/del]

      정말 좋은 글이네요. 공유해주셔서 감사합니다..

      Reply

    submit

    Scott Hanselman 이라는 사람이 오래전 부터 그의 블로그에 좋은 윈도용 소프트웨어들을 소개해주어 유용하게 읽곤 했었는데, 오늘은 올린 글은 입이 떡 벌어질 만큼 특별히 잘 정리되어 있어서 소개를 하고 싶다.

    나는 윈도를 떠나 산지 시간이 좀 흘러서 새로나온 (끝내줘보이는) 도구도 꽤나 보였고, 약간의 향수(?) 마저 느꼈다.

    윈도우즈 프로그래머 혹은 윈도를 사용하는 프로그래머라면 꼭 읽어보고, 모르는 것들이 있었다면 하나씩 설치해서 연습해보면 세상 사는 게 좀 더 편해질 것이라 확신한다.

    http://www.hanselman.com/blog/ScottHanselmans2014UltimateDeveloperAndPowerUsersToolListForWindows.aspx

    저작자 표시 비영리 동일 조건 변경 허락
    신고

    submit
    코딩 호러의 이펙티브 프로그래밍 - 10점
    제프 앳우드 지음, 임백준 옮김/위키북스

    내가 가장 좋아했던 프로그래밍 블로그는 단연 레이몬드 첸의 OldNewThing 이었는데, 최근에 윈도우즈와 동떨어져 사는 생활을 해서 그런지 1등 블로그가 바뀌어 버리게 되었는데 그것은 바로 스택 오버플로를 만들었던 제프 앳우드의 코딩 호러라는 블로그이다. -이전에도 두 블로그를 모두 구독했고 지금도 여전히 레이몬드의 글을 보지만 두 블로그들 중 제프 앳우드의 블로그에 새 글이 올라왔을 때 더 반가운 느낌을 받는 듯 하다.


    6개월 쯤 전이었던가 이 책이 전자책으로 나온 것을 알았을 때 즉시 구입했던 기억이 난다. 아이패드에 넣어 다니며 조금씩 읽긴 했는데 영어책을 읽는 것은 시간과 에너지를 낭비하게 하고 스트레스를 가져다 줬다.

    그래서 이번에 한글책이 나오자마자 기쁘게 다시 구입해서 주말 내내 폭풍처럼 읽어버렸다.(그렇지 않았으면 1년이 지나도 결국 못 읽은 책으로 남았을 것이다)


    결론만 이야기 하면 이 책은 정말 재미있고 유익한 조언이 많이 담긴 책이다. 내가 지금까지 가장 즐겁고 행복하게 (몇 번씩이나) 읽었던 컴퓨터 책은 해커와 화가조엘 온 소프트웨어 정도가 떠오르는데 이제 이 책이 하나 더 추가될 것 같다.


    프로그래밍을 사랑하고 좋은 프로그래머가 되기를 원한다면 꼭 한번 읽어보기를 권장한다.


    저작자 표시 비영리 동일 조건 변경 허락
    신고
    1. fullc0de at 2013.04.23 14:48 신고 [edit/del]

      저도 이거 나왔을 때 사서 읽어봤는데 역시나 좋은 내용이 많더군요. 요즘 팀에 신입사원들에게 읽어보라고 강요(?)하고 있다는;;;

      Reply
    2. fullc0de at 2013.04.24 16:29 신고 [edit/del]

      파트마다 각 한 명씩 들어왔어요~^^ 근데 유지보수가 대부분인 조직에 들어와서 좀 안쓰럽기는 함;;

      Reply

    submit

    요즘 내가 아주 만족스럽게 쓰고 있는 서비스가 두 개 있는데, 하나는 카카오 플레이스이고 다른 하나는 왓챠이다.


    카카오 플레이스는 새로운 맛집을 찾으러 갈 때 주로 사용하는데, 기존의 윙버스나 맛집 블로그처럼 모르는 사람들한테 속지 않을 수 있다는게 큰 장점이다. 여유로운 시간에 내 친구들이 추천해주는 맛집을 하나씩 담아놓고 나중에 하나씩 찾아다니는 맛이 아주 좋다. 물론 속은 적은 한번도 없었고 퀄리티가 모두 내 기대를 만족시켜줬기 때문에 정말 행복하게 사용하고 있다. 뭐 속고 나더라도 그 사람이 추천해주는 맛집은 더 이상 안 믿으면 되기도 하고.ㅋ


    플레이스는 아직 오픈한지 얼마 안된 따끈따끈한 서비스이다. 나는 특수관계인(?)이기 때문에 이미 많은 플레이스 친구들을 가지고 있지만 대부분의 사람들은 친구가 별로 없을 것이다. 친구가 많을 수록 그 재미를 알 수 있는 서비스인데 이것은 시간이 해결해줄 것으로 기대한다.


    또 다른 서비스인 왓챠는 영화 추천 서비스인데 기존에 재밌게 봤던 작품이나 그 장르에 기반해서 자동으로 영화를 추천해주는 서비스이다. 카카오 플레이스처럼 친구 누구가 재밌게 봤다는 힌트도 건네준다. 얼마전 리뷰수 800만을 넘었는데 점점 더 빠른 속도로 성장하고 있는 것 같다.

    지금 글을 쓰면서 하이퍼링크를 걸어주려고 들어가봤는데 이렇게 장애가 나있기도한 서비스이다. -_-;


    내가 왓챠를 좋아하는 가장 큰 이유는 특정 연대, 장르를 지정해서 영화를 추천받을 수 있다는 것이다. 보고 싶은 영화들을 담아놓고 별점순으로 정리할 수 있다는 것도 정말 큰 매력. 최근에 나는 주말에 한번씩 왓챠에 들어가서 보고 싶은 영화들을 담아두는 동시에 한 편씩 감상하고 있는데, 끝내주는 영화를 만날 때 마다 너무 행복해진다.


    나는 어디를 잘 돌아다니지 않고 거의 회사와 집에만 있는 타입이라 바깥 세상이 어떻게 돌아가는지 잘 모르는 편인데, 이런 서비스들로 인해서 문화 생활을 많이 하는 사람들과의 지식? 혹은 정보 격차를 크게 줄일 수 있는 것 같아서 참 좋게 생각한다.

    마치 구글이 나와서 사람들의 지식 수준을 상향 평준화 시켰을 때의 느낌이랄까? 물론 플레이스나 왓챠는 구글만큼 크게 세상에 공헌할 수는 없겠지만 그래도 내가 생활하는데 있어서 기존보다 좀 더 나은 세상을 제공해주고 있는 것은 맞다. 그래서 사랑한다.

    저작자 표시 비영리 동일 조건 변경 허락
    신고

    submit


    Portable Executable Structure이미지 출처 https://code.google.com/p/corkami/wiki/PE101

    엄청나게 잘 정리된 그림을 발견했다. 아름답지 아니한가.

    저작자 표시 비영리 동일 조건 변경 허락
    신고

    submit
    스마트 플랫폼 전략 - 9점
    황병선 지음/한빛미디어

    제목과 꼭 들어맞는 내용으로 알차게 구성되어 있는 잘 쓰여진 책이다.

    첫 삼분의 일은 플랫폼이란 무엇인지 왜 중요한지에 대해서 할애하고 나머지 삼분의 이는 애플과 구글 그리고 마이크로소프트에 대해서 이야기 한다. 이 세 회사를 삼국지로 빗대서 이야기한 책들이 이전에도 몇 권 있었는데, 이 책에서는 그들의 플랫폼 전략을 바라보는 관점에서 이야기를 하기 때문에 단순히 재미뿐만 아니라 영양가도 많이 있었다. 과거의 역사를 돌아보고 왜 성공했는지 혹은 왜 실패했는지와 앞으로 각 회사들의 플랫폼 영향력이 어떤 식으로 발전할지에 대해서 저자 나름의 주장을 하는데, 기술적으로나 전략적으로나 아주 잘 분석했다는 생각이 든다.

    모바일 플랫폼에 관심이 있는 사람들이 꼭 한번 읽어보기를 추천한다.


    P.S 구글이 비록 모토로라를 인수했지만 저자는 이런 저런 이유를 대면서 자체 스마트폰은 아마도 제작하지 않을 것이라 예상했는데, 그 예측은 보기 좋게 빗나간 것 같다. 개인적으로는 루머가 사실이길 바라고 있으며 빨리 완성된 제품을 보고 싶다.

    저작자 표시 비영리 동일 조건 변경 허락
    신고

    submit

    전자책 이야기

    2012.08.20 08:00 | 에세이

    요즘 전자책 읽는 재미에 빠져서 살고 있다. 책이라면 당연히 종이 냄새 나는 종이책이지! 라고 생각했었는데 이 빌어먹을 디지털 세상의 편리함에 또 한가지를 굴복해 버리고 말았다.


    몇몇 책들을 구입해서 실제로 읽다보니 과거에 어렴풋이 생각했던 공간 절약이나 검색 기능 말고도 다른 장점들이 있었다.


    1. 구입 즉시 볼 수 있다. 이건 정말 중요하다. 충동구매가 많이 늘었다;

    2. 소스 코드를 타이핑 하지 않고 원하는 만큼 복사해서 붙여넣기 할 수 있다. 타이핑 안하면 실력이 안 늘어난다고? 그런지 아닌지는 모르겠지만, 걱정되면 직접 치면 되니깐.

    3. 사용자가 선호하는 폰트로 책을 볼 수도 있다. 나는 나눔폰트를 참 좋아하는데 책으로 읽을 땐 어떤 느낌일지 궁금하다. 한 번 보고 싶다.

    4. 책을 보며 밑줄 긋고 낙서해도 쉽게 복원할 수 있다.

    5. 하이퍼링크를 통해 참고자료나 인용 등을 바로 확인 할 수 있어서 편리하다. 물론 원래 보던 페이지로 쉽게 돌아갈 수도 있다.

    6. 출판사 입장에서 책을 컬러로 만드는 것이 덜 부담스럽다. 소스코드는 Syntax 하이라이트를 해서 예쁘게 표현하기도 쉽다. 당연히 사용자한테도 좋다.

    7. 책 페이지수가 종이책에 비해 중요하지 않아졌다. 출판사 입장에서는 레이아웃 구성을 좀 더 자유롭게 할 수 있다.

    8. 대중 교통에서 한 손으로 들고 보기에 편리하다.

    9. 그래도 종이책으로 보는 것이 무조건 좋다고? 선호하는 종이에 인쇄해서 보면 된다.

    10. 종이책보다 싸다. 이전에는 전자책하고 종이책하고 차이가 별로 안나서 이렇게 비싸게 파나? 생각한 적도 있었는데, 지금은 전혀 그렇게 생각하지 않는다. 어짜피 들어있는 지식은 같고, 쓸데없는 공간 안 차지하는 것만으로도 충분히 훌륭하다.


    몇 달전 인사이트에서 처음으로 전자책을 DRM free로 내놨었는데, 계속 해서 새 책이 안나오는 걸 보면 기대했던 것 만큼 반응이 좋지 않았나 보다. 이제 한빛 미디어에서도 전자책 장사를 시작했다. 부디 잘 기획해서 책도 많이 팔리고 시장이 빨리 성장했으면 좋겠다.

    저작자 표시 비영리 동일 조건 변경 허락
    신고
    1. Favicon of http://www.lcpass.com BlogIcon lcpass at 2012.11.12 10:07 신고 [edit/del]

      호불호가 갈리지만 나름 긍정적으로 생각하고 있습니다.

      Reply
    2. Favicon of http://sunyzero.tistory.com BlogIcon sunyzero at 2012.12.14 01:19 신고 [edit/del]

      전자책이 편리성만 따진다면 엄청 편리하더군요.
      오타도 쉽게 업데이트 할 수 있다고 합니다.
      개인적으로는 전자책이 활성화되면 좋겠지만 출판사들이 수익성이 영 안좋다고 하는 소리가 있네요.

      Reply
      • Favicon of http://www.benjaminlog.com BlogIcon 김재호 at 2012.12.15 14:04 신고 [edit/del]

        오랜만에 오셨군요^^
        전자책에 대해서 요즘 생각이 다시 좀 바뀌었는데;;
        편리하긴 엄청 편리한데, 책 보는 시간이 확 줄어버렸네요. 집중력도 엄청 떨어지고.

    submit

    스택오버플로우 오픈소스라는 검색어를 통해 내 블로그에 찾아오는 사람들이 있다. 아마 우리나라 사람들 중 누군가가 스택오버플로우 같은 멋진 커뮤니티를 만들고 싶은가보다. 이미 그런 시도들이 있었고 아래와 같은 사이트들이 만들어졌지만 아쉽게도 기대했던 것 만큼 장사가 잘 되고 있는 것 같지는 않다.

    http://codejob.co.kr/code/

    http://nullpointr.com/


    아참, 그래서 스택오버플로우의 오픈소스가 있냐고?

    있다.

    http://askbot.com/

    정확히 말하면 스택오버플로우의 오픈소스는 아니고 그냥 똑같이 따라서 만들어보려는 클론, 다시 말하면 짝퉁이다. 스택오버플로우에 비하면 부족하긴 하지만 그나마 가장 잘 따라했으며 완성도가 높다. GitHub에 가면 코드를 내려받을 수 있다.

    저작자 표시 비영리 동일 조건 변경 허락
    신고
    1. 주의사신 at 2012.06.25 08:45 신고 [edit/del]

      1. StackOverflow를 만든 Joel Spolsky와 Jeff Atwood의 RSS Feed를 받는 사람의 수는 중복 제거하고도 10만명은 될 것입니다.

      제가 아는 개발자 수가 100명이 안 됩니다. 흥행이 실패하는 것이 어떻게 보면 당연합니다....ㅜㅜ

      만들어 보고서야 뭐가 원인인지 알게 되었네요. 만들기만 하면 다 될 것이라 생각했던 것이 가장 큰 패인이었습니다...


      2. 우선은 놔 둬 보고 계속 조금씩 개선해 나가는 수밖에 없다는 것이 제 개인적인 생각입니다.

      Reply
    2. Favicon of http://codeflow.co.kr BlogIcon 지반 at 2013.07.09 18:18 신고 [edit/del]

      codeflow.co.kr 이란 사이트를 열었는데, 김재호님이 오래전에 쓰신글을 뒤늦게 읽어보고 느낀점이 많습니다.
      일단 codeflow도 stackoverflow 의 클론, 그러니까 비슷한 시스템을 도입한 사이트입니다.
      한가지 추가된 점이 있다면 번역게시판이 있어서, 영문으로 된 사이트의 IT관련 신문 기사나, Q&A 페이지의 글을 서로 번역해주는 게시판을 운영하고 있습니다.

      언급하신 코트잡이나 널포인터 사이트의 2013년 현재상황을 보면 어떻게 codeflow를 흥보하고 운영해야 좋을지 참으로 고민됩니다. 시간나시면 사이트 들러주시고 피드백을 남겨주시면 큰 힘이 되겠습니다.

      감사합니다

      Reply

    submit
    읽기 좋은 코드가 좋은 코드다 - 10점
    더스틴 보즈웰 & 트레버 파우커 지음, 임백준 옮김/한빛미디어

    한빛미디어에서 새로 나온 신간이며 국내 개발자들에게 꽤 유명한 임백준씨가 내용을 옮겼다.
    원서는 The Art of Readable Code라는 책인데 아마존에서도 그럭저럭 호평을 받고 있는 것으로 보여진다.


    책 제목처럼 읽기 쉬운 코드를 쓰는 방법에 대해서 구체적으로 설명한다. 책 분량도 적당하고 내용도 어렵지 않다.

    아주 깔끔하게 잘 나온 책이라고 생각한다.


    하지만 새로운 지식이나 멋진 뭔가를 얻으려고 생각하면 안된다. 책을 읽어가다 보면 아마 기존에 자신이 코드를 작성하면서 대부분 한번씩 고민해 봤을 내용들일 것이다. 이 책의 저자들은 보통 사람들보다 조금 더 많이 고민해 본 것이 확실해 보인다.

    책을 읽어 가면서 자신이 이전에 생각했던 내용들과 비교하면서, 읽기 좋은 코드를 작성하는 방법에 대해서 다시 한번 진지하게 생각해보는 계기를 가진다면 좋을 것이다.


    아참, 책 내용 중에 이런 글이 있었다.

    우리가 이 장에서 설명하는 건 헝가리언 표기법보다 더 넓고 비공식적인 시스템이다. 어떤 변수가 가지는 중요한 속성을 포착한 다음, 그 속성에 중요한 의미가 있으면 변수명에 포함시키는 방법이다. 원한다면 이 방법을 '잉글리쉬 표기법'이라고 불러도 좋다.


    으음, 원하지 않는다.

    변수 이름을 잘 지어야 한다고 노래를 부르더니 정작 본인들은 이름을 이렇게 밖에 못 짓나? 크크크.

    저작자 표시 비영리 동일 조건 변경 허락
    신고
    1. binho at 2012.05.28 11:53 신고 [edit/del]

      좋은책소개 감사합니다. 재밌어보이네요.

      Reply
    2. mapark at 2012.10.22 09:53 신고 [edit/del]

      좋은 리뷰 감사히 잘 읽고 갑니당^^

      Reply
    3. Ashton at 2012.11.09 20:57 신고 [edit/del]

      평이 이렇게 좋은 김재호..잘 모르겠습니다. 너무도 당연한 내용과 때때로 뜬금없는.. 모든 실무에 동일하게 적용할수 있는 룰은 없다는 건 알지만.. 아쉽게도 이번 책 선택은 실패!

      Reply

    submit

    http://www.brianbondy.com/blog/id/140/

    위 포스트를 읽고서 윈도8에 꽤 큰 변화가 생겼다는 것을 알았다.

    지금까지는 UAC를 꺼둔다면 XP와 같은 환경이라고 생각해도 별 문제가 없었지만, 이제는 더 이상 아니라는 뜻.


    If (IsUacDisabled())

    {

    }


    만일 이런 이상한 얍삽이 코드를 즐겨 사용했다면, 이제 그 결정에 대해서 벌을 받을 시간이다.

    저작자 표시 비영리 동일 조건 변경 허락
    신고

    submit

    마이크로소프트에서 카사블랑카라고 이름지어진 흥미로운 라이브러리를 발표했다.


    http_client bing( L”http://www.bing.com/search” );
    bing.request( methods::GET, L”?q=S.Somasegar” )
    .then( []( http_response response ) {
    cout << “HTML SOURCE:” << endl << response.to_string() << endl; })
    .wait();


    listener::create( argv[1], []( http_request req ) {
    req.reply( status_codes::OK, “Namaste!” ); })
    .listen( []{ fgetc( stdin ); } )
    .wait();


    여기 공식 페이지에 간략하게 소개가 있으며, 허브 셔터가 자신의 블로그에 따로 소개해주기도 하였다.

    아마 Restful api를 제공하는 서비스들의 클라이언트 코드로써 가장 많이 사용되지 않을까 싶다.

     

    얼마전 있었던 마이크로소프트의 Going Native 2012 행사에서 허브 셔터가 말하길,

    C++ 언어는 다른 최신 언어들에 비해 부족한 점이 거의 없다. 부족한 것은 바로 라이브러리이다. 라는 말을 했었는데 아주 인상 깊게 들었다. 프리젠테이션 자료를 너무 인상적으로 만들어서 더욱 설득 당했는지도 모르겠다.

    아래 주소에서 그 동영상을 볼 수 있다. 1시간 17분 쯤부터 보기 시작하면 된다.

    http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/C-11-VC-11-and-Beyond


    어쨌거나 좋은 C++ 라이브러리들이 빨리 빨리 구현되기를 바란다. 그래야 Going Native Again 할 것 아닌가.



     

    저작자 표시 비영리 동일 조건 변경 허락
    신고

    submit


    크롬이 4.0이 될 때 부터 어쩌면 1등 브라우저가 될 수 있을 것 같다고 생각한 적이 있다.

    그 때는 그다지 확신을 가졌던 건 아니었는데 이제는 누가 봐도 1등이 되는건 시간문제라고 생각할 것 같다.

    가장 맘에 드는 기능은 동기화 기능이다. 확장 플러그인과 주소 목록, 비밀번호 동기화 등 다른 컴퓨터에 앉았을 때도 쉽게 내 환경을 불러 올 수 있어 편리한데다가, 모바일에서 또한 내가 자주 가는 사이트의 주소 자동 완성과 비밀번호 자동 입력이 지원되므로 불편하게 꼬물 핸드폰 키보드로 타이핑 할 필요가 없어서 너무 좋다. - 현재는 안드로이드 4.0 이상 기기만 크롬을 설치할 수 있다.

    게다가 크롬 확장 플러그인으로 SSH Client도 생겼다. 크롬북에서 특히 유용할 것 같지 않은가?

    삼성에서 언젠가 크롬북을 50만원 정도에 팔았었는데 이건 거품이 심하게 끼었다고 생각한다. 가격이 20만원 대로 내려가고 무게가 조금 더 가벼워진다면 크롬북을 꼭 가지고 싶어질 것 같다.


    저작자 표시 비영리 동일 조건 변경 허락
    신고

    submit

    카카오톡 음모론

    2012.04.26 08:37 | 에세이

    카카오톡의 채용 공고를 재밌게 읽다가 밑에 달린 댓글을 보고 폭소하였다.


    [채용공고]

    카카오팀에서 모바일의 미래를 함께 만들어 갈 만렙 엔지니어를 찾습니다

    카카오톡을 전 우주 통신규약으로 만들려는 음모를 가진 카카오팀에 합류할 실력자를 찾고 있습니다.

    ...하략...



    으하하. 아직 음모를 잃지 않은 만랩 엔지니어들은 한번 지원해보기 바란다. 전체 공지 내용은 여기에서 볼 수 있다.

    저작자 표시 비영리 동일 조건 변경 허락
    신고

    '에세이' 카테고리의 다른 글

    최근에 은행과 병원에서 겪은 이야기  (1) 2014.06.03
    전자책 이야기  (3) 2012.08.20
    카카오톡 음모론  (0) 2012.04.26
    Write in C  (0) 2012.04.23
    Devon 2011, 왜 김택진이 욕을 먹어야 하는가  (2) 2011.11.28
    안철수연구소 오픈 하우스 이벤트  (0) 2011.10.22

    submit

    한 때 윈도우 프로그래밍의 교과서로 불리우던 찰스 펫졸드의 Programming Windows 가 6판이 되어 돌아온다. 추가되는 내용은 윈도8의 메트로 앱개발.


    아직 정식 책이 나오려면 많이 기다려야 하기 때문에 매트로앱에 대한 내용만을 담아서 전자책으로 10$에 파는 이벤트를 진행 한다고 한다. 5월 17일 ~ 5월 31일 사이에만 살 수 있다.


    더 자세한 내용은 그의 블로그에서.

    http://www.charlespetzold.com/blog/2012/04/2-4-6-8-10.html

    저작자 표시 비영리 동일 조건 변경 허락
    신고

    submit

    Write in C

    2012.04.23 22:44 | 에세이



    저작자 표시 비영리 동일 조건 변경 허락
    신고

    '에세이' 카테고리의 다른 글

    전자책 이야기  (3) 2012.08.20
    카카오톡 음모론  (0) 2012.04.26
    Write in C  (0) 2012.04.23
    Devon 2011, 왜 김택진이 욕을 먹어야 하는가  (2) 2011.11.28
    안철수연구소 오픈 하우스 이벤트  (0) 2011.10.22
    플라워 바이 겐조  (0) 2011.07.12

    submit

    살다보면(?) 매크로에서 받는 가변 인자를 또 다른 매크로로 쑤셔넣고 싶은 경우가 있다.

    #define MACRO_1(abcfn(a, b, c) #define MACRO(...) MACRO_1(__VA_ARGS__)

    짠, 이렇게 하면 된다.

    그렇다. 아무 테크닉이 필요없이 그냥 쑤셔넣으면 된다.

    그런데 위 코드는 GCC에서는 잘 동작하지만 VC에서는 동작하지 않는다. 그렇다고 해서 가변인자는 다른 매크로로 건넬 수가 없구나 하고 오해하면 안된다. 이것은 그냥 비주얼 스튜디오의 버그일 뿐이다.

    #define MACRO_1(abcfn(abc)
    #define MACRO_1_(args_listMACRO_1 args_list
    #define MACRO(...) MACRO_1_((__VA_ARGS__))

    비주얼 스튜디오에서는 위와 같은 얍삽이를 통해서 이를 회피할 수 있다. __VA_ARGS__ 주위를 한 겹 더 괄호로 둘러싸서 또 다른 매크로로 넘기는 것을 주의해서 봐야한다.


    그래서 내가 하고 싶은 말은,


    이 버그가 정말 거지 같다고 생각된다면

    http://connect.microsoft.com/VisualStudio/feedback/details/380090/variadic-macro-replacement

    여기 가서 upvote를 해주세요.

    저작자 표시 비영리 동일 조건 변경 허락
    신고

    submit