골빈해커의 3분 딥러닝 텐서플로맛

  • title
  • github.com/golbin/TensorFlow-Tutorials
  • 장점; 얇은 책이 갖는 전형적인 장점을 갖는다. 수식이나 이론적인 이야기들보다 코드를 통한 실습에 중점을 두어 부담없이 읽을 수 있다. 책 출간 시점까지 최신의 내용을 담으려고 노력했다.
  • 단점; 얇은 책이 갖는 전형적인 단점도 갖는다. (물론 개인 실력의 문제이긴 하지만 나의 경우) 읽고 나서 뭘 해보려고 해도 기초가 없이 봤더니 감이 잘 안 잡힌다. 기초가 없는 경우 읽기 전후로 기초 강의를 듣고 반복적으로 보는 게 좋을 거 같다.
  • 결론; 당연한 말이지만, 기초가 없는 경우 많은 노력이 필요하다. 그래도 다가가기 어렵다는 생각이 들 때 시작을 하기 쉽게 도와준다는 점 만으로도 가치가 있다고 생각한다.
  • tip; 실습할 때 version이 바뀌고 설치도 귀찮은 경우 docker를 이용하면 편리하다. 조금 큰 걸 돌리려고 하면 속도가 많이 느리지만, 간단한 예제 정도는 간단히 할 수 있다.
    • docker로 tensorflow image를 가져와서 실행
      • 1
    • jupyter notebook 접속
      • 2
Read More

Flask development server, single threaded, synchronous, ...

  • 상황
    • flask API server에서 다른 server(tornado)를 호출해 결과를 만드는 API가 있는데, 결과가 비정상
    • 비정상인 이유는 중간에 timeout이 발생했기 때문
  • 아주 간략한 전체 흐름
    • 0
    • ePattern API를 시작하면 (내부 콜은 생략하고) Extract API를 호출
    • Extract API는 library call로 sparser 호출
    • sparser가 Entity API를 호출
    • 리턴, 리턴, 리턴이 발생하면 정상 종료
  • ePattern API는 requests.get으로 Extract API를 호출
    • 1
  • sparser는 libcurl의 curl_easy_perform으로 Entity API를 호출
    • 2
  • timeout 발생 이유
    • 3
    • sparser는 Entity API의 리턴을 기다리지만, 여기서 timeout이 발생
    • 왜냐하면 flask server는 ePattern에 대한 리턴값을 Extract API에게서 기다리는 중이라, 이걸 먼저 해결해야 그 다음 Entity API를 처리해줄 수 있기 때문
  • 해결 방법
    1. storage API의 흐름을 asynchronous하게 (X)
      • flask development server가 single threaded + synchronous
      • 이걸 async로 만드는 플러그인이나 기타 다른 방법이 있지만, 번거롭기도 할 뿐더러 성능상 이점이 있는지, 안정적인지 알 수가 없음
    2. storage API의 Entity / ePattern을 별도 서버로 만들어서 각각 호출 (O)
      • 가능 하고 간단
      • 지금까지 한 서버에서 호출하면서 url만 다르게 하던 걸 port를 바꿔서 해야 하고, 소스 관리가 조금 귀찮아짐
    3. production을 위해 준비했던 apache server 사용 (O)
      • 원래 서비스용으로 준비했던 apache server를 이용하면, multi threaded로 동작하기때문에 위와 같은 문제가 발생하지 않을 걸로 생각했고, 실제로 해결
Read More

Change IP address for cloudera manager

  • 상황; server 이전으로 인해 cloudera manager로 관리하는 hadoop server들의 ip address가 변경
  • server 이전하기 전 처리 내역; cloudera manager에서 cluster및 cloudera management service 정지 후
Read More

Review of AWS Lambda

처음 시작하는 AWS 람다

  • aws lambda
  • 프로그래밍 관련 소식이나 블로그를 보다 보면 몇 년새 AWS에 대한 이야기가 폭발적으로 늘어났다는 걸 알 수 있다. 그와 함께 서버리스 아키텍쳐에 대한 관심도 증가하면서 자연스레 AWS lambda에 대한 소식도 많이 볼 수 있다. AWS lambda에 대해 관심은 있지만, 선뜻 시작하기 어렵게 느껴질 때 보기 좋은 책이란 생각이 든다
  • 장점
    • 정말 실제로 사용해본 경험을 바탕으로 썼다는 점이 느껴진다. 특히 lambda를 사용하지 않아야 하는 경우를 설명하는 14장이나, 비용에 대해 알려주는 19장의 경우가 좋았다
  • 단점
    • node.js로 예제를 설명했는데, 비교적 간단하다고 하지만, 사용해본 적이 없는 입장에서 약간 거북할 수 밖에 없었다(물론 node.js 사용자라면 반대로 장점)
    • AWS 관련 서비스를 실제로 사용해본 적이 없는 사용자라면, 좀 헤멜수도 있다고 예상한다. 한꺼번에 많은 이야기가 나오니 초반부(hello world 예제) 이후로는 따라가기가 좀 버거웠다. 책의 컨셉 자체가 빠르고 간단하게 볼 수 있도록 군더더기를 제거하고, 각 장도 짧게 구성하려 한 점은 이해할 수 있으나, 대상이 초중급이라면 조금만 더 보기 쉽게 설명하면 좋겠단 생각이 든다
Read More

Review of Essential Scrum

(성공적인 애자일 도입을 위한) 에센셜 스크럼

  • 별 생각없이 도서관에 신청했던 책인데, 책이 도착해서 빌리고 보니 마침 요즘 내 상황에 필요한 책이었다. 두껍고 당장 어디에 쓸 건 아니라 자세히는 아니지만, 하룻만에 읽었는데, 너무 복잡하고 자세해서 필요없는 부분도 있었지만, 소득도 있었다. 애자일과 스크럼에 대해 관심이 있다면 확실히 추천할 만한 책이란 생각이 든다
  • 맘에 안 든 부분
    • 스크럼 자체가 복잡해서 그런건지, 아니면 저자가 가능한 모든 걸 풀어서 설명하려고 해서 그런지는 모르겠지만, 아무튼 책이 두껍고 복잡한데다, 실제로 업무에 적용하려면 쉽게 할 수 있을지 잘 모르겠다
    • 예를 들어 prioritized와 ordered 중 어느 용어가 적절한지 논란을 하는 게 개발자에게 무슨 의미가 있을까?
  • 맘에 든 부분
    • 정말 자세하게 설명한다…는 나에게 큰 장점은 아니지만, 관심이 있는 사람에게는 (열심히 읽으면) 도움이 될 거 같다
    • 하나는 확실하다. 책의 시작이 우선순위를 결정하는 일이라는 점을 통해, 어떤 일을 하건 어떤 프로세스를 사용하건 항상 최우선으로 할 일은 할 일을 정하고, 일의 순위를 결정하는 일이라는 걸 다시 한 번 확인할 수 있었다
    • 이어달리기의 비유, “선수들이 아니라 배턴을 봐야 한다”
      • 모든 선수들이 100% 바쁘게 한다고 해서 릴레이 경주에서 금메달을 딸 수 없다. 바닥에서 뒹구는 배턴은, 제품 개발 상황에 비유하면, 할 준비는 되어 있지만 필요한 자원을 기다리느라 중단된 일과 비슷하다. 배턴이 땅 위에 있을 때는 경주, 즉 제품 생산에서 이기지 못한다
      • 직원이 아니라 일에 초점을 맞춰야 한다는 의미
      • 단 이어달리기 경주 방식으로 다른 사람에게 일을 전달하는 건, 우리가 피해야 할 전통적, 순차적 제품 개발 방식
  • 몇 가지 기억할 부분
    • 스프린트
      • 67
      • 스크럼 프레임워크의 뼈대로, 짧거나 지속적인 기간을 가지며, 한 번 시작한 이상 바뀌어서는 안 되는 목표를 가지며, 팀이 정의한 완료에 최종적으로 도달해야 한다
      • 목표를 제대로 정하고, 한 번 정하면 무조건 완료해야 한다는 뜻일까? 빈번하게 바뀌는 상황에 대응하려면, 스프린트가 짧아야 하기 때문에 최대 1개월로 정의하는 걸까?
    • 제품책임자
      • 191
      • 제품 리더십의 중심점이며 권한을 부여받은 사람으로 최소한 두 가지 방향을 볼 수 있어야 한다
      • 제품 관리자로서 조직의 이해관계자들, 고객, 사용자들의 목소리를 대변할 수 있을 만큼 그들의 필요와 우선순위를 반드시 잘 이해해야 한다
      • 무엇을 만들어야 하며 어떤 순서로 만들지를 개발 팀에게 반드시 전달해야 한다. 반드시 제품 기능 인수 기준이 명시되었는지 확인하고 이 기준을 검증하는 테스트가 기능 완료를 결정하기 위해 나중에 실행되는지 확인해야 한다. 테스트를 자세히 작성하지는 않지만, 상위 수준의 테스트가 작성되었는지 확인하고, 이 테스트를 사용해 언제 기능이 완료되었다고 판단한다
      • 즉 일부 비즈니스 애널리스트, 일부 테스터
    • 스크럼마스터
      • 216
      • 217
      • 애자일 코치로, 개발 팀과 제품 책임자 양측의 역할 모두를 코칭해 역할 간 장벽을 없애고 제품 책임자가 직접적으로 개발을 주도할 수 있게 한다
      • 스포츠 팀의 코치와 비슷하게, 팀이 스크럼을 어떻게 사용하는지 관찰하고, 팀이 다음 수준의 능력에 도달할 수 있도록 돕기 위해 할 수 있는 모든 일을 한다
      • 스스로 문제를 해결할 수 있도록 돕기 위해 있지만, 팀이 문제를 해결할 수 없다면 스크럼마스터가 이를 주도적으로 해결한다
      • 제품 책임자와의 관계는 스포츠 팀 구단주와 팀 코치의 관계와 같다. 제품 책임자가 스크럼을 이용해 비즈니스 결과를 최대화할 수 있도록 돕고, 기대치를 관리하고, 제품책임자가 팀이 필요한 것을 제공하도록 하고, 제품 책임자의 불만과 변화에 대한 요구사항을 듣고 팀을 위해 이를 행동 가능한 개선점으로 해석한다
        • 이 부분은 이해가 잘 가지 않음
      • 서번트 리더, 프로세스 지휘자, 방해 보호막; 이 부분은 이해가 가기는 하지만, 방해 보호막의 역할을 현실적으로 어떻게 할 수 있을까?
  • OKR과의 충돌(?)
    • OKR은 지금까지 이해한 바로는 달성할 수 없는 목표(목표의 60~70%만 달성하면 성공으로 간주)를 세우고 노력하는 건데, 스크럼의 경우 스프린트는 무조건 완주해야 하는 목표를 세우고 스프린트를 반복하는 거라면, 이 둘을 같이 하려는 리더는 어떻게 이해해야 할까?
Read More

Review of Munch book

뭉크

  • munch
  • 도서관에서 우연히 발견하고 아주 재미있게 읽은 책. 뭉크에 대해 새로운 면도 알게 되었고, 재미있게 읽었다. 뭉크의 생애를 주로 어디서 그의 예술작품이 기인했는지에 초첨을 맞춰 그렸다는 생각이 든다
  • 예술가들에게서 흔히 볼 수 있는 점
    • 여성편력. 분야에 관계없이 정말 흔히 볼 수 있는 특징(?) 책임감 없이 헤어지고, 나중에 그리워하는 것도 마찬가지
    • 정신병에 걸릴 지경인 가정환경
      • 144p
      • 204p
      • 276p
    • 아버지에 대한 감정
      • 200p
  • 약간 다른 점
    • 의외의 정치력? 장학금을 받기 위한 타협
      • 170p
    • 살해의도? 루드비히 카쉬튼에게 총을 쏘려고 함
  • 그림
    • 눈에 보이는 게 아니라 자기가 본 것을 그리기 위한 여정
      • 175p
      • 203p
      • 255p
    • 절규
    • 같은 주제의 그림을 반복해서 그리는 건 디버깅?
  • 기타
    • 100년 넘은 집
      • 178p
    • 기성 세대에 대한 불만
      • 216p
Read More

Review of wordpress book

만들면서 배우는 워드프레스

  • 한빛 미디어에서 리뷰를 제안해서 읽어보게 되었다. 워드프레스는 관심만 있었지 실제로 써보지는 못했는데, 좋은 기회가 될 거 같아 바로 하겠다고 말씀을 드려서 책을 받게 되었다.
  • 책을 처음 받고 우선 대략 훑어보니, 개발자용 책은 아니고, 무료나 가능한 적은 비용으로 자신의 홈페이지를 운영할 사람들을 대상으로 한 책이었다. 호스팅부터 시작해서 설치, 사용 방법 및 필요한 플러그인에 대해 가능하면 자세하게 설명한 걸로 보였다. 나는 무료 호스팅 서비스를 사용할 계획이 없어서, 어떤 방식으로 설치를 해볼까 하다가 docker를 사용해 설치하면 간단하게 테스트할 수 있을 거 같아, 이 방법을 쓰기로 결정했다.
  • 검색을 하면 다음과 같은 link를 쉽게 찾을 수 있고, 해당 설명대로 docker-compose.yml만 만들고, docker compose up -d 명령을 주면 아래와 같이 docker가 구동이 된다.
Read More

진중권의 생각의 지도

  • book.daum.net link
  • 요즘 들어 책 읽는 속도가 정말 엄청나게 느려졌다. 나이가 들어서 느려지기도 했고, 예전만큼 책 읽는데 시간을 쓰지 못하는 탓이기도 하다. 그래서 읽을 책을 고르는 데 더 신중해야 하기도 한다. 쌓여있는 읽을 책 리스트는 엄청나게 많지만, 다 읽을 수가 없으니.
  • 생각의 지도는 가장 최근에 구입한(몇 달 전) 책이다. 여전히 이름만으로 택하는 거의 유일한 저자의 책이다. 미학자로서 쓴 책들은, 처음 그의 책을 읽은지 수십년이 지났지만 여전히 유효하고 오히려 더 재미있다. 이번에도 읽고 나니, 내가 뭔가 더 잘 알게 된 건 없어도 책 자체가 재미있고, 뭔가 뿌듯하다. 이번 책도 개정판인걸 보면 정치 관련 발언 논란이 있어도 인기가 식지는 않은 거 같다.
  • 씨네 21에 연재했던 글을 모은 책이라 짧은 글을 주제별로 묶어서 10개 장으로 이뤄져 있다. 생각같아서는 모든 글을 정리하고 싶지만, 가장 기억에 남는 두 가지만 정리해봤다.
  • 4부 13 - 눈에 뵈는 아무 증거 없어도 - 신앙주의에 관하여
    • ‘불합리하기 때문에 믿는다는 말’은 사실 아리스토텔레스의 ‘누군가가 믿기 힘든 말을 하더라도 혹시 그것이 진실일지도 모른다고 생각하라’는 말을 배경으로 뒀다고 한다. 그냥 믿으라는 말이 아니라, 조심스럽게 생각하라는 뜻이었으나 잘못 인용해왔던 것.
    • 물론 신앙이 합리적이라면 이미 과학의 범주에 포함이 되거나 필요없어졌을테니 일견 맞기는 하다. 하지만 외부자들의 입장에서 보면 믿음에서 증거를 얻고, 증거는 믿음을 통해진다는 건 명백한 순환논법의 오류이니(히브리서 11:1, 2절을 예로 들었음), 신앙인들과 비신앙인들의 충돌은 필연적일 수 밖에 없다.
    • 창조과학은 신앙에 증거를 제시하려는 방법인데, 신앙주의가 반대하는 게 ‘증거가 있어야 믿는다’는 이라는 걸 생각해보면, 증거주의에 발판을 둔 창조과학이 하는 일 - 현대 과학의 불완전함을 드러내는 - 자체가 논리적 오류나 비약이다.
    • ‘믿음이 증거를 앞선다’는 신앙주의는 수학의 공리와 같은 걸 생각해보면 꼭 틀린 것은 아니기는 하다. 수학에서는 공리를 통해 정리를 증명하고, 정리를 통해 명제를 증명하는데, 공리는 ‘증명 없이 참인 명제’이기 때문에 수학이라는 이성도 그 기초는 믿음에 근거한다고 볼 수 있기 때문이다. 법도 명령/조례의 올바름은 법률에 따라 판단하고, 법률은 헌법에 따라 판단을 하지만, 헌법 그 자체는 그런 증명이 필요가 없다. 헌법의 진리는 혁명이나 전쟁, 쿠데타에 의해 완결되기 때문이다. 비트겐슈타인에 따르면 언어가 작동하려면 화자들이 기본적인 신념을 공유해야 참/거짓을 따지는 언어놀이가 가능하다고 한다.
    • 그런데 수학은 전 인류가, 헌법은 국민 전체가, 언어의 기본적 신념은 언어공동체가 공유하기 때문에 증명 없이 참으로 통하는 전제들을 받아들일 수 있지만, 종교의 경우 신도와 비신도가 있고, 신도간에도 종파의 차이가 있어 공리에 해당하는 부분을 공유할 수 없기 때문에, 증거없이 믿는 다는 게 불가능해지고, 신도에게는 공리이지만, 비신도에게는 증거를 봐야 믿을 수 있는 사건이 된다는 점.
    • 여기서 약간 맥락이 다를 수 있지만, 시오노나나미의 종교의 유대인 철학의 그리스인 법의 로마인 설명이 생각이 났다. 종교는 믿는 사람들에게만 유효하고, 철학은 이해하는 사람들에게만 유효하지만, 법은 누구에게나 적용이 된다는.
  • 9부 - 예술의 진리
    • 작가 이름과 작품명을 줄줄 외워대는 ‘지각’으로 예술을 대하지 말라. 송곳같은 ‘감각’을 되살려 예술에 숨어있는 진리를 마주하라
    • 언제나 원하지만 얻지 못하는, 나에게는 너무나 어려운 일. 고흐같이 내가 정말 좋아하는 작가를 대할 때나 아주 조금 이해할 수 있다. 물론 그 전에 저런 감각을 얻기 위한 훈련이 정말 필요한데, 직접 작품을 대하고 느끼고 반추하는 등의 경험(훈련, 연습이란 말은 나에게는 과하니까)이 없으면 거의 불가능한 일인데, 그럴 환경이 되지 않으니 정말 아쉽다.
Read More

만약 헤밍웨이가 자바스크립트로 코딩한다면

  • 만약 헤밍웨이가 자바스크립트로 코딩한다면
  • 한빛미디어 리뷰어에 신청했는데, 당첨이 되고 나서 받은 책이라 읽게 되었다. 자바스크립트는 정말 기초만 알고, 사용하지도 않기 때문에 내가 책을 선택할 수 있었다면 아마 하지 않았을 것이다. 게다가 일종의 편견이긴 하지만, 개발 서적을 개발자가 아니라 번역가가 하는 경우(이 책의 저자는 그래도 좀 나은 게 개발자 영어라는 페이스북 그룹을 운영하는 분으로 나프다에도 출연)는 보통 기술적으로 오류가 있는 경우가 많아 좋아하지 않기도 한다.
  • 하지만, 왠지 폼 나보이는 책 제목에, 리뷰를 써야 한다는 의무감이 겹쳐 읽기 시작했는데, 의외로 금방 읽을 수 있었다. 빨리 읽을 수 있었던 이유는 유명한 작가들에 관한 이야기가 재미있기도 하고, 자바스크립트를 모르니, 코드를 읽기는 하지만, 이해가 안 되는 부분을 하나씩 분석해볼 시간이 없어 그냥 읽고 넘겼기 때문이다.
  • 저자는 문학에 대해 관심이 많고, 아주 잘 아는 거 같다. 코드를 보면 자바스크립트를 모르는 사람이라도, 정말 다양한 스타일로 썼다는 걸 알 수 있다. 하지만 문제는 독자도 잘 알아야 이해할 수 있다는 점이 문제이다. 자바스크립트를 사용하며(이런 개발자는 많겠지), 동시에 문학에 대해 잘 알고(대폭 감소), 작가의 스타일을 이해하며(대폭 감소), 그 미묘한 문학적 차이까지 이해하려면 과연 얼마나 남을까? 게다가 이건 번역서라 원래는 해당 작가의 언어로 책을 읽어야 한다는 걸 생각하면…
Read More

Scala, Covariant, Contravariant

Covariant, Contravariant

  • function간의 subtype 관계는 어떻게 형성되는가에 관한 문제
  • 이해가 안 가서 그림을 그려서 이해해보려고 했는데, 이해가 안 되도 바로 알 수 있게 한 마디로 정리해줬다.
    • function argument는 contravariant, return value는 covariant
  • problem1
    • answer1
  • problem2
    • answer2_1
    • answer2_2
    • answer2_3
Read More

You're up and running!

Next you can update your site name, avatar and other options using the _config.yml file in the root of your repository (shown below).

Read More