일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- erlang
- Kuala Lumpur
- Book review
- history
- hadoop
- Programming
- hbase
- Java
- psychology
- Spain
- Software Engineering
- web
- ubuntu
- France
- Malaysia
- management
- Book
- RFID
- Italy
- QT
- Python
- comic agile
- agile
- MySQL
- programming_book
- leadership
- program
- Linux
- essay
- django
- Today
- Total
목록Book review (211)
작업 환경이 자신의 작업 리듬을 모두 수용할 수 있을 만큼 유연하다면, 저항에 부딪혀 고군분투할 필요가 없어진다. 크게 성공한 사람들에 관한 연구 결과를 보면, 성공은 저항을 극복하는 능력이나 강인한 의지력의 결과가 아니라 애초에 저항력이 생기지 않게 방지하는 스마트한 작업 환경의 결과라는 것이 여러 차례 입증되었다. … 직관적으로 대부분의 사람들은 단순한 아이디어에는 많은 것을 기대하지 않는다. 인상적인 결과를 얻으려면 그만큼 인상적으로 복잡하고 어려운 수단이 있어야 한다고 추정하기 때문이다. 헨리 포드 Henty Ford와 동시대를 살았던 사람들은 컨베이어벨트처럼 단순한 물건이 어째서 그토록 혁명적인지 납득하지 못했다. (정말 필요한 건 뭐든 simple하게 하는 거 일수도. routine한 flow..
하지만 늘, 이유는 알 수 없으나 온건파는 과격파보다 불리하다. 논리적으로 호소하기보다 신념에 호소하는 편이 더 많은 사람에게 영향을 줄 수 있기 때문일까. 관행, 기득권 수정의 어려움. 무엇보다 내가 지금 실감하고 있다. 외교상의 접촉도 건물과 마찬가지로 기초부터 신중하게 쌓지 않으면 무너지고 마는 것이다. 피보나치와 프리드리히의 관련성. 이건 처음 알게 되었다. 시오노 나나미의 시그니쳐같은 구절이 아닐까? 고대 로마인인 율리우스 카이사르도 말했다. “인간이라고 누구나 현실의 모든 것을 보는 게 아니다. 많은 사람은 보고 싶은 현실만 본다.” 정보를 활용할 수 있는 사람은 보고 싶지 않은 현실도 직시하는 사람뿐이다. 책임 소재를 분명히 한다는 것. 어떤 종류건 이게 업무에서 가장 어려운 일 중 하나. ..
세계사의 중심에서 언제나 빠지지 않는 유대인. 호불호는 있겠지만, 대단하다는 점에서는 의견 불일치가 없을 듯 설득의 어려움, 일화의 중요성 아무리 많은 지원이 있더라도 결국 어떤 새로운 길을 개척하기 위해서는 선각자, 간단히는 천재, 가 필요하다. 역사에서 가끔 볼 수 있는 뭐든 다 잘하는 천재의 전형인 듯 동기 부여의 중요함 사내에서는 자유롭게 공유, 사외에서는 기본적으로 사내의 내용이 confidential인 거와 비슷한 듯(e.g. 카카오의 100:0 원칙) 정말 알기쉬운, 절묘한 비유 이름이야 워낙 유명해서 알고 있었는데 방식 자체가 전혀 다르다는 건 처음 알게 됨 닐스 보어 책에서도 읽었던 부분. 그런데 인간은 비합리적이다. 진정한 “과학" 과제는 그렇지. 하지만 이건 처음부터 “과학"적인 의도..
개인적으로 시간을 낼 수도 없고, 회사도 기회를 제공하지 않은 상태로 시간만 보내게 되는 겁니다. (지금 이 문제로 내가 싸우고 있어서 정말 와닿는다) 소프트웨어 개발 프로젝트의 복잡도는 크게 두 가지 변수의 영향을 받습니다. 그것은 바로 ‘사용자 요구사항’과 ‘개발기술’인데요. 먼저 ‘사용자 요구사항’ 의 경우를 보죠. 폭포수개발방식은 프로젝트 초기에 요구사항을 고정시킵니다. 사용자와 철저한 인터뷰를 하고 문서를 만들며, 여기에 확인 서명을 받기도 하죠. 이에 반해, 애자일 방식은 요구사항의 변화를 그대로 수용합니다. 다만 반복적인 프로세스를 돌려서, 각 프로세스(이터레이션 또는 스프린트) 안에서는 요구사항이 변하지 않도록 보호하는 조치를 합니다. 그럼 기술의 변화는 어떻게 수용할까요? 프로젝트 초반에..
기술적 요구를 기반으로 경계를 그리는 것은 안티 패턴이다. 제임스 루이스와 마틴 파울러에 따르면 마이크로서비스는 기술적 요구가 아닌 ‘비즈니스 기능을 중심으로 구성’되어야 한다. 마찬가지로 데이비드 파나스 Davial Pumus는 시간에 따른 설계 변경의 모듈식 캡슐화를 기반으로 시스템을 분해할 것을 권장한다. 두 접근 방식 모두 서버리스 함수의 경계와는 일치하지 않는다. 서비스 경계를 정할 때 다음과 같은 설계를 위해 노력해야 한다고 제안했다. 느슨한 결합: 서비스는 서로를 인식하지 않고 독립적이어야 하며, 한 서비스에서 코드를 수정하더라도 다른 서비스에 영향을 주지 않아야 한다. 높은 응집력: 서비스에 있는 기능은 관련성이 높아야 하며 관련 없는 기능은 다른 곳에 캡슐화되어야 한다. 이렇게 하면 기능..
사무라이는 원래 해군과는 무관한 존재들이다. 창검술, 기마에 대한 이들의 집착은 거의 종교적인 것이었다. 그만큼 해군 육성이라는 발상의 전환은 용이한 것이 아니었다. 그러나 쇼인도, 료마도 이런 오랜 전통과 관례를 끊어버리고 해군 양성의 절박성을 바로 간파했다. 역사의 갈림길은 이런 데서 비롯된다. 일본어로 친구는 ‘도모다치’인데 하기 사투리로는 ‘찡구’란다. 그리고 그 말은 한국말의 친구에서 왔다는 것이다. 그 유명한 초망굴기론이다. ‘초망’이란 우거진 풀, 잡초라는 뜻이니 권력을 지니지 않은 재야나 시정에 있는 사람들을 말한다. 쇼인이 이 말을 쓰면서 의식한 계층은 하급사무라이, 그 밑의 졸병에 해당하는 사람들, 나아가 유력한 상인, 농민 등, 지식 있고 뜻있는 민중까지였다. ‘굴기’란 말은 중국의 ..
가볍게 읽을 수 있는 오쿠다 히데오의 가족에 대한 단편 소설들. 일본이라 그런지 모르지만 사람 사는 게 다 비슷하구나 하는 생각을 하게 만드는, 가족간의 사랑을 슬며시 느끼게 하는 소설들이다. 재미있거나 맘에 드는 표현들을 몇 가지 모아봤다. “우는 부인에게 아무 말도 안 했어? 진짜 냉혈한이구나. 파충류도 준이치 씨보다는 친절하겠다.” “그리고 빨리 아이를 만들어. 애가 생기면 너는 버려진 자전거 신세가 될 테니까.” 만약 남편이 프로 야구 선수인데 후보로 저 벤치에 앉아 있다가 대타로 나가 범퇴로 아웃당하는 바람에 온 일본의 무책임한 샐러리맨들에게 욕설을 듣게 된다면 도저히 못 견디고 화장실로 도망치고 말 것이다. (그래서 나이가 들면서 2군 선수들에게 오히려 관심이 가고 응원팀이어도 선수들에게 나쁜..
간단히 정리한다면 “농업혁명, 허구, 문자” 골드마인: 물론 개인의 관점에서 보면 농업은 위대한 아이디어가 아닐지도 모릅니다. 하지만 호모 사피엔스 주식회사의 관점에서 보면 굉장한 성공담이죠! 곡식 재배는 단위 면적당 훨씬 많은 식량을 보장했습니다. 그것이 호모 사피엔스가 기하급수적으로 늘어날 수 있었던 비결입니다! … 한 종의 DNA, 본이 점점 더 많아진다면 그건 진화적으로 대성공이죠. 하라리: 농업 덕분에 지구상에 더 많은 사람이 살게 됐지만 그들은 더 비참해졌어요 제정신이라면 누가 호모 사피엔스의 유전자 사본을 늘리기 위해 자신의 생활 수준을 낮추겠습니까? DNA 사본 수로 평가한다면 이것을 해석할 방법은 오직하나, 가축 닭이 역사상 가장 성공한 가금류라는 겁니다. 닭 다음에는 한참 뒤처지긴 하지..
프로그래밍과 직접 연관된 부분은 거의 없지만, 여러가지 시사점을 제공하며, 좀 더 나은 프로그래밍을 하는 데 많은 도움을 줄 수 있는 주제들을 다룬다. 프로그래밍, 소프트웨어 공학이 발전하면서 세부적인 주제들, 일견 관련이 없어 보이는 부분들을 다루는 쪽으로도 나아가는데, 이 책 역시 그런 종류의 책이다. 예를 들어, 코드를 작성하는 것만큼, 어쩌면 그보다 더 코드를 읽는 게 중요하다는 사실은 최소한 경력이 있는 개발자들에겐 잘 알려진 사실이다. 하지만 이런 작업이 뇌와 어떻게 연결되고, 어떻게 동작하는지에 대해 쓴 책이 아마 이 책이 최초가 아닐까? 개인적으로는 비개발자들에게 개발자의 작업을 이해시키는데 유용하게 쓸만한 근거 자료들을 찾을 수 있어서 당장 직접적인 도움도 되었고, 프로그래밍을 이해하고 ..
정리를 잘해서 prolog만 읽어도 이 책의 주제를 바로 이해할 수 있다. 30년의 커리어 패스를 쌓기 위해 단계별로 나아가기 위한 정보를 알려주는 게 이 책의 목적이다. 대부분의 junior 개발자들은 평생 개발을 하는 걸 원하는 경우가 많고, 또 좋은 code를 작성하는 게 개발의 대부분이라고 생각하는 경우가 많다(최소한 예전에는 그랬다). 하지만 실제 업무를 하다 보면 우리가 흔히 soft skill이라 부르는 여러 가지 code 이외의 능력도 업무에 큰 영향을 주며(대표적인 게 communication), 또 사람의 앞 일은 알 수 없기에 자의건 타의건 lead를 하고 management를 할 수도 있다. 저자는 크게 엔지니어링, 매니지먼트, 비즈니스 역량이라는 3가지 대주제로 9가지 기술을 익혀..