IT 책장

Microservices Patterns

Audible에서 Audio Book으로도 들을 수 있다. https://www.audible.com/pd/Microservices-Patterns-Audiobook/B07ZFZ464G 참고 링크 https://microservices.io/patterns/microservices.html https://eventuate.io/ 인상 깊은 단락 (번역판 페이지 기준) p92 DDD와 마이크로서비스 아키텍처는 거의 찰떡궁합입니다. DDD의 하위 도메인, 경게 컨텍스트 개념은 마이크로서비스 아키텍처의 서비스와 잘 맞고, 마이크로서비스 아키텍처의 서비스 자율팀 개념은 도메인 모델을 개별 팀이 소유/개발한다는 DDD 사고방식과 어울립니다. 자체 도메인 모델을 가진 하위 도메인이라는 개념 덕분에 만능 클래스를 제거하고 서비스로 분해하기가 더 수월해집니다. p109 ‘하위 호환되는 소규모 변경'에 ‘속성을 응답을 추가'로 해당.

프로젝트 성공을 결정짓는 성능 시험 방법론과 실무

http://www.yes24.com/Product/Goods/2495264?OzSrank=1 인상 깊은 단락 p22 최근까지도 국내에서 수행되는 대부분의 성능 시험 프로젝트의 경우 성능 시험 도구 라이센스에 대한 비용 부담 및 Think 시간 측정의 어려움, 성능 시험 소요 시간의 단축, 관련자들의 이해 부족 등의 이유로 Think 시간을 배제하거나 대폭 줄인 채로 성능 시험을 실시하고 있는 상황입니다. 이는 시험 목표와는 전혀 다른 결과를 도출할 수 있는 비현실적인 상황을 재현하는 것으로 이를 통해 성능을 개선하는 것은 의미가 없다고 단언할 수 있습니다.

테크니컬 리더

테크니컬 리더: 혁신, 동기부여, 조직화를 통한 문제 해결 리더십 관련 자료 https://www.slideshare.net/mrbin95/ss-16004929

Bridging the communication GAP

인상 깊은 단락 Introduction Agile acceptance testing breaks down traditional boundaries around testing, requirements and specification processes in a way that significantly improves communication on a project. It is intentionally not too technical or suited only for programmers, because agile acceptance testing is not a programming technique: it is a communication technique that brings people involved in a software project closer. One of the main messages I want to convey with this book is that the biggest benefit of agile acceptance testing is improved communication and mutual understanding, not test automation.

Growing Object-Oriented Software, Guided by test

인상 깊은 단락 원서 페이지 기준 p269 로깅에 대한 테스트

역사 속의 소프트웨어 오류

인상 깊은 단락 p21 1997년 대한항공 괌 추락사고로 인해 비상 사태시에 승객이 취해야할 자세에 대한 안전 수칙이 추가 됨. p35 페트리어트 시스템의 오류는 10진수와 2진수 사이의 변환 오차로 인한 것 p56 큐리오시티의 성공에는 분명 MCO의 실패에서 얻은 교훈이 녹아 있었을 것이다. NASA는 MCO 사례 이후 모든 프로젝트 진행시 도량형을 미터법으로 통일하도록 규제했기 때문이다. 도량형 문제로 3억 2,760만 달러(한화 약 4,00억 원, 환율 1,100원 기준)를 허공에 날리면서 얻은 귀중한 교훈이었다.

도메인 주도 설계

인상깊은 단락 서문 반면, 좋은 설계는 이렇나 복잡한 특징을 활용할 기회를 만들어 줄 수 있다. p2 모델은 대상을 단순화한 것이다. 즉, 모델을 어떤 사실을 해석한 것으로 볼 수 있고, 당명한 문제를 해결하는 것과 관련된 측면을 추상화하고 그 밖의 중요하지 않은 세부사항에는 주의를 기울이지 않는다. p3 도메인 모델은 어떤 특정한 다이어그램이 아니라 다이어그램이 전달하고자 하는 아이디어다. 도메인 모델은 단지 도메인 전문가의 머릿속에만 존재하는 지식이 아니라 해당 지식을 엄격하게 구성하고 선택적으로 추상화한 것이다.

Dynamic Programming for Coding Interviews

원서 : Dynamic Programming for Coding Interviews: A Bottom-Up approach to problem solving 번역서 (종이책) 다이내믹 프로그래밍 완전 정복 빠르고 우아한 상향식 문제 풀이법 (이북) 다이내믹 프로그래밍 완전 정복: 빠르고 우아한 상향식 문제 풀이법 (View 옵션이 Original Pages만 지원 ) 감상 2020.07.21 Kindle로 약간 보다가 번역서가 편집이 더 이쁘고 가독성이 좋아서 종이책으로 구입했다. 기술 면접에 적절한 난이도의 문제를 친절히 차근차근 설명했다. 원서의 제목이 저자의 의도에 더 부합하는 듯하다.

자바 프로그래밍 면접, 이렇게 준비한다

감상 2020.07.20 Java8이 나오기 전에 쓰여진 책이라 현시점에서는 오래된 지식이 많다. 기술 역사서로는 의미가 있다. 알고리즘 구현예제들도 최적화의 여지가 있어보인다. 예: Quick Sort는 책의 예제보다 공간복잡도를 더 줄여서 구현할 수 있다. 인상 깊은 단락 p99 Collections.newSetFromMap() 언급. 책에는 오타로 Collection.netSetFromMap() 이라고 되어 있다. p158 Integer.MAX_VALUE 등에 대한 언급. 2의 보수 원리. 아래와 같이도 확인할 수 있다. assertThat(-Integer.MIN_VALUE).isEqualTo(Integer.MIN_VALUE); assertThat(Math.abs(Integer.MIN_VALUE)).isEqualTo(Integer.MIN_VALUE); assertThat(Integer.MIN_VALUE -1).isEqualTo(Integer.MAX_VALUE); p320 https://code.google.com/archive/p/dbdeploy/ 소개.

1년 안에 빅데이터 전문가 되는 법

참고 링크 http://dagyeom.net/ : 저자의 회사 책에 나온 추천 자료 빅데이터 비지니스 (p128-129) 빅데이터 기초:개념, 동인, 기법 인공지능 시대의 비즈니스 전략 빅데이터가 만드는 제4차 산업혁명 빅데이터 비즈니스 이해와 활용 빅데이터 분석과 활용 데이터 마이닝(p134) 데이터 마이닝 개념과 기법 패턴 인식 데이터마이닝 기법과 응용 자격증 교재(p140) 데이터 분석 전문가 가이드 경영 빅데이터 분석사 SQL 전문가 가이드 데이터 분석 코딩(p150) 파이썬 라이브러리를 활용한 데이터 분석 파이썬으로 데이터 주무르기 빅데이터 분석 도구 R 프로그래밍 R라뷰 수리 통계학 수리통계학개론 딥러닝 딥 러닝 제대로 시작하기 인프런 강좌 모두를 위한 딥러닝 - 기본적인 머신러닝과 딥러닝 강좌 밑바닥부터 시작하는 딥러닝 DB Database Concepts 몽고디비 인 액션 추천 알고리즘 Recommender Systems: The Textbook Building Recommender Systems with Machine Learning and AI Deep Neural Networks for YouTube Recommendations Infra (p244) 아마존 웹 서비스 AWS Discovery Book Python 어플리케이션 개발 (p245) 깔끔한 파이썬 탄탄한 백엔드 파이썬으로 배우는 알고리즘 트레이딩 파이썬 GUI 프로그래밍 쿡북 인상 깊은 단락 p39 서울대학교 컴퓨터 공학부 정원이 55명인데 반해 스탠퍼드는 739명

알고리즘 탐정 프랭크

생계형 개발자 SI에서 살아남기

감상 2020.06.30 ( ‘SI에서 비지니스는 쿼리에 있어야 합니다.’ 등 70, 81, 82, 85페이지를 읽고 소감) ‘ArrayList 가 thread safe 하기 때문에'라고 적어놓은 것이 우선 흥미롭다. ‘ArrayList'의 JavaDoc을 보면 그렇지 않다는 것을 바로 알 수 있기 때문이다. ‘Note that this implementation is not synchronized.’ 라는 문구가 굵은 글씨도 강조되어 있다. 저자가 그런것은 관심을 둘 필요가 없다는것을 강조하기 위해 위와 같이 정확하지 않게 기술한 것일수도 있겠다. 암튼 SQL에 최대한 많은 로직을 두고, Java단에는 Map만 넘기는 개발스타일이 SI에서 선호되는 이유는 다음과 같다고 나는 생각한다.

컴퓨터 과학 로드맵

책에서 링크로 걸려있는 https://code.energy/ 의 자료들도 볼만한 것 같다.

누구나 자료구조와 알고리즘

오브젝트

인상 깊은 단락 맥락에 따라 이해해야하므로 책을 사서 전문을 꼭 읽어봐야한다. 들어가며 과학적 패러다임과 프로그래밍 패러다임과 차이점 p3 우리가 사용하는 패러다임은 ‘한 시대의 사회 전체가 공유하는 이론이나 방법, 문제의식 체계'를 의미한다. p5 프로그래밍 패러다임은 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필요한 부분에 대한 의견 충돌을 방지한다. 또한 프로그래밍 패러다임을 교육시킴으로써 동일한 규칙과 방법을 공유하는 개발자로 성장할 수 있도록 준비시킬 수 있다. p6 쿤은 상이한 두 가지 패러다임이 있을 때 두 패러다임은 함께 존재할 수 없다고 주장했다.

개발 7년차, 매니저 1일차

감상 2020.04.18 멘티 개발자, TL, 매니저 등 단계별로 신경을 써야 할 일들을 이 책에서 체계적으로 정리했다고 느껴집니다. 미국 IT 업계를 배경으로 하고 있지만 국내 IT회사에 다니는 분들도 공감이 갈만한 지점이 많습니다. 1On1 미팅을 강조하고 있다는 점도 인상적입니다. 2020.06.30 ‘실리콘밸리의 팀장들’ , ‘개발7년차, 매니저 1일차’, ‘슬랙’ 을 읽고 느낀 점 다른 사람과 협업을 하는 모든 개발자는 ‘관리'의 영역에 있는 일을 신경써야 한다. 관리 업무에서 가장 중요한 지점은 ‘명확한 피드백'을 전달하는 것이고, 때로는 불편한 피드백을 주어야 하는 경우도 있다.

테스트 주도 개발 시작하기

감상 JUnit5에 맞춘 친절한 TDD 책이 나와서 반가웠다.

도메인 주도 설계 핵심

도메인 주도 설계 핵심 : 핵심을 간추린 비즈니스 중심의 설계로 소프트웨어 개발 프로젝트 성공하기 인상깊은 단락 67p 문서 자체는 도메인 모델이 아니다. 더 정확히 말하면 도메인 모델 개발을 두와주는 도구일 뿐이다. ### 129p 규칙2 : 작은 애그리게잇을 설계하라.

알고리즘 도감

Hello Coding 그림으로 개념을 이해하는 알고리즘

자바 코딩 이럴 땐 이렇게

인상 깊은 단락 p96 boolean 반환할때 불필요한 if문 없애기 - 코드리뷰 때 종종 이야기하던 패턴인데 책에서보니 반가웠다. p128 K&R과 1TBS

실리콘밸리의 팀장들

감상 구글/애플에서 관리자를 경험을 하고, 애플대학교에서 ‘애플경영법'을 강의했던 킴스콧이 쓴 책. ‘조직 내에서 건설적이지만 불편할 수도 있는 피드백을 어떻게 잘 주고 받을 것인가?‘가 이 책의 핵심 화두이다. 중간중간 나오는 쉐릴 샌버그, 에릭슈미츠, 스티브잡스 같은 거물들의 일화들도 흥미롭다. 인상 깊은 단락 33 (‘최고의 상사는 감정노동의 달인’ 단락) 사람들은 상사가 느끼는 ‘감정 노동'을 과소평가하며, 대개 서비사람들은 상사가 느끼는 ‘감정 노동'을 과소평가하며, 대개 서비스나 의료 산업에 종사하는 사람들, 예를 들면 정신과 의사나 간호사, 웨이터 항공 승무원이 느끼는 일로 치부한다.

나는 LINE 개발자입니다

나는 LINE 개발자입니다 : 라인의 개발 고수 12인의 도전과 기회, 성장의 개발 라이프 감상 2019.09.21 책의 저자분들이 다들 글을 잘 쓰셔서 잘 읽혔고, 출퇴근길에 재밌게 빠르게 읽을수 있었다. 아는 분들이 나와서 반갑기도했다. 개발자들이 경험을 풀어놓은 이런 책을 좋아해서 가급적 사본다. 책이 아니었다면 술자리에서 몇시간 동안 이야기해야 들을수 있는 이야기일법하다. 이 책의 책값 만이천원으로 12번의 술자리를 대신한 느낌이다. https://www.facebook.com/benelog/posts/2422516247784435

Talking To Humans

인상 깊은 단락 p44 B2B 회사인 경우, 스티브 블랭크 교수는 C-레벨 사람들보다는 중간 레벨 관리자들과 인터뷰를 시작하는 것을 추천하고 있다. 약속을 잡기 더 수월할 것이며, 반복적인 대화를 하기에도 더욱 쉬울 것이다. 가장 중요 한 것은 더 높은 사람을 만나기 전에 더 잘 배울 수 있는 기회를 갖는 것 이다 p98 헨리 포드 (역자주: 포드 자동사 회사 창립자)가 말한 유명한 Henry Ford 문구가 있다. ‘제가 사람들에게 무엇을 원하는지 물었다면, 더 빠른 말 이라고 답할 것입니다’

함께 자라기

http://ebook.insightbook.co.kr/book/65 에서 PDF로 구매할 수 있다. https://www.yes24.com/Product/Goods/67350256?OzSrank=1 관련 링크 https://zzsza.github.io/etc/2018/12/16/agile-together/ 인상깊은 내용 p31 자기계발이 왜 중요하다고 생각하냐면, 현재 나에게 무엇을 투자했느냐가 1년, 혹은 2년 후의 나를 결정한다고 느끼기 때문입니다. 예를 들어 올해 업무도 잘한 것 같고 사람들에게 인정을 받은 것 같다면 1~2년 전을 잘 되돌아봅니다. 아마 그때 열심히 자기투자를 했을 겁니다. 반대로 올해 읽은 책도 몇 권 없고 새로 얻은 통찰도 없다면 지금 당장은 별 문제없는 것 같지만 (예를 들어 올해 내 연봉은 만족스러우나) 내년이나 내후년에는 분명 추락을 경험할 것입니다.

스프링 5.0 마이크로서비스

인상 깊은 단락 2ed p76 scale cube 참고 http://theartofscalability.com/ https://microservices.io/articles/scalecube.html 요약 x축 : 애플리케이션을 복제해서 수평적으로 확장 y축 : 서로 다른 기능들을 분리 Z축 : 데이터 파티셔닝 또는 샤딩 p188 https://github.com/Nilhcem/FakeSMTP 를 이용한 테스트 환경 구성 https://github.com/benelog/devnote/blob/master/smtp.adoc 에 관련 도구들을 정리했다. p218 공유 데이터 모델, 공유 스키마, 공유 테이블은 좋지 못한 방법이며, 마이크로서비스 개발을 재앙으로 이끌 수도 있다. 처음에는 좋은 수도 있지만, 복잡한 마이크로서비스를 개발하다 보면 데이터 모델 사이에 계속 관계를 추가하고, 조인 쿼리를 만들어내게 된다.

그림으로 배우는 HTTP & Network

인상 깊은 단락 p112 end to end 헤더와 hop-by-hop 헤더 구분 p119 Cache-control : max-age 헤더 관련 설명 p153 referrer 오타 언급

코딩 시대

http://www.yes24.com/Product/Goods/38894134?OzSrank=1 인상 깊은 단락 148 제임스 고슬링이 자바 언어를 만들었던 의도가 웹을 만나면서 현실화 된 것이다. 149 이희승 님 언급 203 초등학생이라면 피지컬 컴퓨팅 추천 284 네이버 D2 소개

자바 웹 프로그래밍 Next Step

https://github.com/slipp/jwp-book 피드백 의견 : https://github.com/slipp/jwp-book/issues?q=is%3Aissue+author%3Abenelog

그림으로 배우는 알고리즘

DDD START!

DDD START!: 도메인 주도 설계 구현과 핵심 개념 익히기 인상 깊은 단락 p36 p85 p128 p165

단순한 디자인이 성공한다

인상 깊은 단락 52p 글을 쓴다는 것은 어려운 작업이다. 명확한 문장은 그냥 나오는 것이 아니다. 처음부터, 심지어 세번째에도 제대로 된 문장이 나오는 경우는 드물다. 절망의 순간에 이것을 이억하라. 글을 쓰는 것이 힘든 이유는 그것이 원래 힘든 일이기 때문이다. - 엘리엄 진저 ‘글씨기 생각쓰기’ 돌베개, 2007년 중에서 116p 극단적으로 없앤 애플스토어의 엘레베이터 사례 144p 색상을 사용해 정보의 레이어를 구분하는 것은 인간 두뇌의 동작 원리를 이용하는 것이기 때문에 사용자에게 주는 부담이 매우 적다.

자바 객체지향의 원리와 이해

정리 116쪽 MSDN 원문일부 (https://msdn.microsoft.com/en-us/library/27db6csx%28v=vs.90%29.aspx) In an “is a” relationship, the derived class is clearly a kind of the base class.

JPA 프로그래밍

정리 485쪽 쿼리 보이는 옵션 켜기 hibernate.show_sql 옵션 켜기 org.hibernate.SQL = debug org.hibernate.type = TRACE

객체 지향의 사실과 오해

인상싶은 내용 31쪽 외부의 도움을 무시한 채 모든 것을 스스로 처리하려고 하는 전지전능한 객체(god object)는 내부적인 복잡도에 의해 자멸하고 만다. 68쪽 소프트웨어 안에 구축되는 객체지향 세계는 현실을 모방한 것이 아니다. 현실의 모숩을 조금 참조할 뿐 궁극적인 목적은 현실과 전혀 다른 새로운 세계를 창조하는 것이다. 또한 객체지향 세계는 현실의 추상화가 아니다. 오히려 객체지향 세계의 거리는 현실 속의 객체보다 더 많은 특징과 능력을 보유한 객체들로 넘쳐난다. 131쪽 이름에서 풍기는 늬앙스와는 달리 테스트-주도 개발은 테스트 작성이 아니다.

실리콘밸리 견문록

인상 깊은 단락 p42 옆자리 증후군 (the next-bench syndrome) 이라는 단어의 유래도 HP다. 옆자리 동료에게 도움이 될 만한 기술이라면 개발할 가치가 있다는 뜻이다. 휴렛이 어느날 거대한 계산기를 보며 주머니에 들어가는 휴대용 계산기가 있으면 좋겠다는 아이디어를 낸다. 마케팅 부서에서 그런 계산기는 10배나 비쌀텐데 누가 사겠냐고 묻자, 휴렛은 가니느 살 거라며 개발을 시작한다. 거기에서 휴대용 전자 계산기 시장이 생겨났다. p87 신규 직원 한명당 평균 350만원 정도다. 이해를 돕기 위해 비교를 해보자면, 구인활동에 쓰는 비용이 직원 한 명을 훈련하는 비용의 세 배에 이른다고 한다.

스프링을 이용한 RESTful 웹 서비스 구축하기

스프링을 이용한 RESTful 웹 서비스: 구축하기 실전 예제로 배우는 REST 방식의 스프링 웹 서비스 인상 깊은 단락 p194 http://goessner.net/articles/JsonPath/ https://github.com/FasterXML/jackson-module-jaxb-annotations/wiki

Functional Programming in Java 8

http://www.yes24.com/Product/Goods/13488109?OzSrank=1 11쪽 함수형 스타일은 객체 지향 프로그램(OOP) 방법을 거스르는 것이 아니다. 실제 패러다임의 변화는 명령형 스타일에서 서술적 스타일로 변경됐다는 것이다. 73쪽 파라미터 라우팅 177쪽 이거( eager) 방식은 간단하지만 레이지(lazy)방식은 효율적이다.

인프라 엔지니어의 교과서

http://www.yes24.com/24/Goods/13486433?Acode=10 인상 깊은 단락 184,185 우선 역할을 세가지로 나눴다. 지금을 보는 역할, 1개월 후를 보는 역할, 그리고 3개월 후를 보는 역할이다. (중략.) 그리고 3개월후를 보는 역할을 맡은 사람은 이른바 인프라 전략을 담당한다. 인프라 구축에는 아무리 해도 시간이 걸리는 일이 있다. 서버 구매와 데이터 센터 스페이스 증강에는 보통 몇개월씩 걸린다. 회사로서도 투자액이 많은 부분이기도 하니, 경영진의 결재를 얻기 위해선 자료를 많이 준비할 필요가 있다.”

개발자의 코드

이미지 출처 : http://www.yes24.com/Product/Goods/8489379 인상 깊은 단락 p20 설령 예전에 작성한 것을 이용하여 재구현하기로 결정한 경우라도 주석 처리했던 코드는 통상적으로 딱 들어맞는 경우가 흔치 않다. p39 침실 밖에서 일하라 p60 일정이 너무 상세하고 인도날짜가 너무 자주 다가온다면 진행하면서 애플리케이션의 세부사항을 실험하고 재고려할 재량권이 없어진다. 우리는 마치 무지하면서 사소한 일까지 챙기는 관리자가 끊임없이 우리 주위를 맴도는 것과 같이 추측된 태스크의 융퉁성 없는 일정을 고수할 수 밖에 없는 상황에 놓일 것이다.

데이터가 보인다

인상싶은 내용 226쪽 기업 내외의 환경을 분석할때 이용되는 프레임워크로는 다음과 같은 것이 있다. 3C분석 : Customer, Conpany, Competitor PEST 분석 : Politics, Economy, Socieity, Technology

폴리글랫 프로그래밍

인상 깊은 부분 62쪽 비록 자바 8이 스칼라나 C#의 람다에서 사용하는 ‘=>’ 기호 대신 작대기를 하나 슬그머니 내려놓은 ‘->’ 기호를 사용하는 것이 거슬리긴 하지만. 그 정도의 수준에서 자존심을 세우려는 것은 참아줄 수 있다 64쪽 (Joshua Bloch의 인터뷰) 우리가 자바에 클로저를 더 한다면 그것은 이미 지원되고 있는 문법의 테두리 안에서 조심스럽게 이루어져야할 것입니다. 즉, 클로저가 내부에 하나의 메서드만 가지고 있는 인터페이스를 구현하는 형태를 가져야한다는 뜻입니다. Runnable 같은 인터페이스나 TimerTask같은 클래스처럼 말입니다.

파이쎤 웹 프로그래밍

인상싶은 내용 73쪽 플라스크의 세션은 서버 사이드 세션이 아닌 암호화된 쿠키형태 148쪽 서버사이드 Cache를 이용한 세션구현, Redis를 이용한 세션 구현

프로그래머 철학을 만나다

인상깊은 부분 p16 우울증을 앓는 사람은 우울한 기분의 원인을 외부에서 찾으려는 경향성을 나타낸다. … 자신의 내면을 통제하고 관리하는 사람은 다른 사람이 자신을 좋아하지 않는다는 사실을 받아들일 수 있다. 타인이 자신을 싫어한다고 하여 자신을 증오하는 우를 범하지 않는다. p27 미육군의 리더십 메뉴얼에는 “리더는 스트레스 상황에서도 평성심을 유지하고 자신이 긍정적으로 영향을 줄 수 있는 일들에 대해서 에너지를 쏟으며, 자신이 영향을 끼칠 수 없는 일을 걱정하지 않는 것이 무척 중요하다"는 항목이 있다.

코딩을 지탱하는 기술

참고할 단락 p117 IEEE 754가 정의하고 있는 부동 소수점 구조

Debug it! 실용주의 디버깅

( 이미지 출처 Yes24 : http://www.yes24.com/24/Goods/3937865?Acode=101 ) 감상 선배로부터 들었던 주옥같은 조언들, 평소 막연히 생각은 했지만 체계화하지 못했던 원칙들이 잘 정리되어 있다. 특정 개발환경에만 국한되지 않는 보편적인 원칙들로 채워져 있어서, 시간이 지나도 이 책의 가치는 바래지지 않을듯.. 인상 깊은 부분 p65 동시에 여러 개를 변경하면 잘못된 결론에 이를 수 있다. p68 뭐든지 우리가 이해하지 못하는 부분은 잠재적인 버그다. p76 디버깅은 순간이지만 테스트는 남는다. 디버거가 디버깅 방법 중에서 가장 강력한 것임에는 틀림없다.

개발자가 반드시 알아야 할 자바 성능 튜닝 이야기

http://www.yes24.com/Product/Goods/11261731?OzSrank=1 인상 깊은 단락 32쪽 nanoTime()메서드는 만든 목적은 수행된 시간 측정이기 때문에 오늘의 날짜는 알아내는 부분에는 사용하면 안 된다. 157쪽 JDK5부터는 -XXX:+UseBiasedLocking라는 옵션을 통해서 biased lock이라는 기능을 제공한다. 210쪽 일부 회사에서는 자체 개발한 프레임워크를 사용하는데, 필자는 제발 그러지 말아줬으면 좋겠다. 214쪽 Apache Httpd의 keep alive 설정을 on 358쪽 GC로그 분석 툴소게. HPJmeter는 아파치의 JMeter와는 전혀 상관이 없는 모티러링 및 분석툴. 408쪽 AWStats와 Piwik소개 423쪽 튜닝결과 정리시의 유의점

3D 프린터의 모든 것

인상 싶은 단락 p88 기존 2D 프린터의 최강자인 HP는 미래를 준비해야 했기 때문이다. 카메라의 절대강자와도 같았던 이스트먼 코닥이 디지털 카메라의 시대를 만나면서 무너졌던 것을 잘 알기 때문이다.

벤츠 타는 프로그래머

감상 고등학교 때 축제 준비로 게임을 만든 이야기는 비슷한 추억이 있어서 반가웠고, 벤츠를 사는 걸 30대의 목표로 했다는 부분은 내가 차에 관심이 없어서인지 그다지 와닿지는 않는다. 벤츠는 언제 나오나 계속 궁금해하면서 읽었는데, 책의 후반부에 ‘그림6-1'로 나온다.. 그외에도 애자일, 게임 개발, 오픈소스 프로젝트, 개인사업 등 다양한 분야에 대한 저자의 경험을 이야기했다. 우리 나라 저자가 쓴 이런 종류의 책을 좋아하는데, 개인적으로 다른 분의 경험을 깊이 들으려면 책값보다 훨씬 비싼 술값, 시간이 들어간다고 생각하기 때문이다.

아마존 웹 서비스 클라우드 디자인 패턴 설계 가이드

인상 깊은 단락 129 s3fs : S3의 버킷을 EC2의 디스크로 마운트

거침없이 배우는 자바스크립트

링크 번역판 소스 : https://github.com/taggon/missing-manual-kr 원서 소스 : http://sawmac.com/js/

라이프해커

라이프해커: 업무의 달인이 알려주는 121가지 업무 비법 인상 깊은 단락 p50 p94 p136 p195 p289 p441 p451 p467 p469

미래를 바꾼 아홉가지 알고리즘

우리에게 IT는 무엇인가

https://www.yes24.com/Product/Goods/8769400?Acode=101 인상 깊은 단락 p28 SOA에 대한 과거 예측 p48 SI의 한계.  훌륭한 프로그램은 남의 집에서 만들어지지 않는다. p57 물질 문명 사회에서는 미처 생각하지 못한 부와 권력의 재구성이 지금 일어나고 있다. p61 정부의 역할 p63 SI사들은 종합건설사 풍의 턴키 제공업자가 아닌 비트이 무역업, 즉 매시업을 지향하는 종합상사로 거듭난다. p69 가상화의 혜택 p82 흉내내기 전략, 차별화, 사실상의 표준 p96 CD의 종말 p114 표준은 많은 경우 승자의 논리다.

해킹과 침투 테스트

감상 입문자에게 눈높이를 맞춰서 맛뵈기로 다양한 도구를 잘 소개했다. 해킹을 예방하는 규칙은 단순하다. 네트워크와 포트는 최소한도로 개방하고, 어플리케이션에 과도한 권한 안주고, 비밀번호 단순하게 하지 않고, 각종 패치 적용 잘하고.. 몰라서 못 지키는것은 아닌데, 설마하는 마음에 지나치기 쉽다. 이 책을 보면 해커들이 얼마나 편하게 쓸 수 있는 도구가 많은지를 알게 되어서 조금은 더 부지런하게 보안에 대비하게 될 것 같다.. 핵심 요약 1. 침투 테스트 소개 백트랙 리눅스 침투 테스트를 위한 종합 백화점

프로그래머로 산다는 것

감상 저자 중 네 분이 지인이라 반가웠다. (유석문 님, 황상철 님, 이상민 님, 김성박 님) p203 만약 여러분들이 신입사원이라면, 3~5년차 이내의 IT 회사에 있는 개발 직군의 직원이라면 개발을 하라. 뒤도 돌아 보지 말고, 주변을 둘러보지 말고 개발을 하라. p212 IT 회사는 머리로 일하는 회사다. 머리를 지속적으로 사용하는 데에는 한계도 있고, 만약 지속해서 개발만 하다 보면 악성 코드가 양성되기 마련이다. 8시간 동안 일한 사람과 12시간 동안 일한 사람 중 누가 더 집중적으로 일할까?

클라우드 컴퓨팅 어플리케이션 아키텍처

감상 2010년 출판된 책이라서 2012년 현 시점에는 다소 맞지 않는 내용이 있다. 예를 들면 Google App Engine이 Python만 지원한다고 써 있는 내용. 관심가는 솔류션 http://www.valtira.com/ http://www.opentext.com/ : CMS 솔류션 http://mesh.com : 각종 디바이스 동기화, 원격 제어 클라우드 관리 솔류션 : http://enstratus.com/, http://www.rightscale.com/ 인상 깊은 내용 p20 마이크로소프트, Xen, VMWare 같은 엔터프라이즈 가상화 기술은 CPU제조업체가 지원하는 하드웨어 지원 가상화 기술을 제공하고, 실제 물리적 서버와 거의 유사한 수준까지 성능을 낸다.

이제는 빅데이터 시대

이미지 출처 Yes24 (https://www.yes24.com/24/Goods/6982605?Acode=101) 감상 105페이지의 얇은책이고 전문적인 내용은 아닐꺼라 생각해서 큰 기대는 안 했다. 그런데 이외로 영감을 주는 사례들이 많았고 재밌었다. 빅데이터로 검찰, 국세청 개혁도 가능하다는 주장이 독창적이다. 빅데이터하고 직접적인 관련이 없는 소감이지만.. 아이폰 출시가 2009년 11월28일, 서울버스 앱은 2009년 12월 3일 출시.. 제작자는 만들면서 무척 재미있었을 것 같다.. 대기업에서는 혹시나 아이디어가 있는 사람이 있었어도 기획서 쓰고, 높으신 분 일정 맞춰서 기획 회의 한 5번하고, 서울시 담당자 한 5번 만나고, 상위기획서, 상세기획서하고 디자이너 할당하고, 개발할 엔지니어 찾는다고 한 2주 걸리고.

어제를 버려라

이미지 출처 Yes24 (http://www.yes24.com/24/goods/7250627?Acode=101) 감상 메모 2012-08-01 2009년4월에 ‘위피'의무 탑재 폐지, 2009년 11월28일에 아이폰 출시.. 그 후로 세상은 엄청나게 빨리 흘러갔고.. 지금 통신사의 mVOIP논란을 보면서, 소비자한테는 더 유리한 길을 제도로 막을 수 있는 시간은 한계가 있지 않을까 하는 생각이 든다.. 책에 나온 카카오톡 직원들의 의견처럼, 결국 통신시장은 음성통화를 공짜로 하는 시대로 가지 않을까? 2012-07-19 시대의 길을 뚫어간 대인배 감상문 2012.07.19 인터넷 업계의 대인, 김범수님의 이야기를 IT전문기자인 임원기님이 기록한 책입니다. 임원기님은 2007년 나왔던 네이버 성공신화의 비밀이라는 책의 저자이기도 합니다.

읽기 좋은 코드가 좋은 코드다

읽기 좋은 코드가 좋은 코드다: 더 나은 코드를 작성하는 간단하고 실전적인 테크닉 인상 깊은 단락 p89 p98 p137 p197 p219

애자일 마스터

생각 메모 프로젝트 목표 공유의 중요성. not list 케이크 - full stack web developer 인상적인 내용 사용자 스토리의 원칙..(INVEST - independent, negotiable, valuable, estiable, small, testable)

거꾸로 배우는 소프트웨어 개발

감상 편하게 잘 읽히는 책. ‘정신없이 개발한 소프트웨어가 제 정신일리 없다’, ‘협업에 대처하는 가장 좋은 방법은 역설적이게도 협업이 필요한 부분을 최소화하는 것인지도 모르겠다’ 같은 마음에 드는 문구들이 몇개 기억에 남는다. 이 시리즈 계속 나왔으면.. 인상 깊은 단락 p20 문명 붕괴의 패턴을 읽다가 소프트웨어 역시 비슷한 양상으로 붕괴한다는 걸 깨달았다. p47 그러나 개발자로서 가장 중요한 language는 우리말입니다. p67 정신없이 개발한 결과물이 제 정신이 있기를 기대하는 건 좀 심하다는 생각이 든다.

Pro web2.0 mashups

인상 깊은 내용 p5 (번역판) 매쉬업과 리믹스라는 용어는 대중가요에서 유래된 말이다. 개략적으로 말하면 리믹스는 원본 음악의 변형된 버전인 반면 매쉬업은 두개나 그 이상의 음악요소를 합친 것을 의미한다. p29 API에 대한 보다 공식적인 정의로서, Programmableweb.com의 존 무써는 다음과 같이 말하고 있다. “하나의 프로그램이 다른 프로그램의 접근을 허용해주어 직접 자신과 통신할 수 있도록 해주는 함수의 집합” p401 23hq의 플리커 API 지원 사례 p668 Firefox에서 Microformat의 학습을 도와주는 Operator 확장기능

도메인 주도 설계란 무엇인가?

도메인 주도 설계란 무엇인가? : 쉽고 간략하게 이해하는 DDD https://www.yes24.com/Product/Goods/5445597?Acode=101 인상깊은 단락 16p 17p 49p 71p 98p 111p

JUnit in Action

인상적인 단락 p5 단위테스트를 ‘다른 단위에 종속되지 않는 하나의 단위에 대한 테스트’ p71 개발자 입장에서 무언가를 잘못 수정할 때마다 바로바로 알려주는 누군가가 곁에 있어주는 것만큼 마음 든든한 일도 업삳. 단위 테스트는 잘못된 부분을 찾기 위해 어플리케이션을 디버깅할 필요성을 줄여준다. 기능 테스트가 버그가 존재하는 유즈케이스를 골라주는 수준이라면, 단위 테스트는 어떤 메서드가 어떤 이유로 실패했는지도 이야기해준다. 즉 문제를 찾아 몇시간씩 헤매던 일에서 해방된다. p99 숨겨진 종속성과 전역상태를 피하라 싱글톤은 애플리케이션에 전역 상태를 만들어낸다는 명백한 취약점이 존재한다.

프로그래머 그 다음 이야기

감상 2014/03/07 임백준님, 이주연님의 뛰어난 글솜씨, 나와 같은 회사를 다니셨던 박재성님의 공감할만한 이야기 덕분에 재미있게 읽었다. 6명의 저자 중 4명이 기술사라서 다양한 진로의 경험을 전달하지 못한 점이 아쉽다. 기술사 시험에 합격하기 위해 얼마나 많은 노력을 했는지 이야기하는 내용이 몇 번 반복되고, 100여자루의 다쓴 볼펜 사진이 두 번이나 나온다. (이춘식님이 147쪽에, 신재용님이 300쪽에) 인상깊은 부분 p133 프로그래머가 프로그램을 실제로 코딩하는데 드는 시간은 얼마나 될까? 1985년 Fairly의 조사에 의하면 프로그래밍 작성에 13% 정도만 소요된다고 한다.

트러블슈팅 이야기

인상싶은 내용 72쪽 ps -Lf -p [pid] 208쪽 vmstat, sar 217쪽 리눅스 커널에서는 메모리의 내부 단편화를 해결하기 위해 슬랩 할당자라는 것을 사용한다. 229쪽 pstree 236쪽 pmap 263쪽 sar로 네트워크 사용량 확인 342쪽 –XX:+PrintConcurrentLocks –XX:+PrintClassHistorygram

웹을 지탱하는 기술

인상깊은 내용 40쪽 버너스-리는 다음 날부터 구현하기 시작해, 그 해 크리스마스 휴가에 첫 버전의 서버와 브라우저를 완성시켰습니다. 54쪽 REST는 웹의 아키텍처 스타일입니다. 아키텍쳐 스타일은 ‘(매크로)아키텍처 패턴'이라고도 하며, 복수의 아키텍처의 공통된 설질, 양식, 규정 호근 독특한 방식을 가리키는말입니다. 아키텍처 스타리엔는 VMC와 파이프 앤 필터, 이벤트 시스템 등이 있습니다. 58쪽 리소스를 한마디로 설명하는, ‘웹상에 존재하는 일믕 가진 모든 정보'가 됩니다. … 리소스의 일므이란 URI를 말합니다.

클라우드 혁명

http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9788994120157&orderClick=LAH&LINK=PSM 인상 깊은 단락 트럭으로 된 MS 데이터 센터 스쿠터를 타고 다니는 구글 데이터 센터 kWh당 11센트 대신 2센트 정도의 수력전기 지대.. 수강신청,이벤트. 하이브리드 클라우드 Rackspace, Amazon 데이터센터 규모를 보여주는 자료.. Cloudwatch, Autoscaling,elastic load balancing MS. 30만대.. 구글 데이터센터 서버 초계 50만~60만대. 대규모 데이터센터들 중에서 서버를 4만5천대 이상 보유한 곳은 없다. 애플, 오레곤에 새 데이터센터 짓는다 밤에는 온도가 내려가 자연 냉각을 이용 가능 많은 수력발전을 만드는 콜롬비아 강에 있는 여러 댐 덕분에 토지와 전력비용이 저렴 VMWare hyperic HQ : x86 하드웨어의 명령집합을 소프트웨어에서 모방 EC2는 Xen 가상머신을 수정 p104 : VMWare의 수석과학자 리눅스는 군살 빼기에 좋다.

소프트웨어 아키텍트가 알아야할 97가지 이야기

인상 깊은 단락 6쪽 기교로써 단지 대화에 익숙해지는 것만으로는 충분하지 않습니다. 존경심을 가지고 사람을 대하는 것을 배우고, 사람에 대한 성급한 판단을 버리는 것을 배우는 것이 영리한 아키텍트가 유능한 아키텍트로 변하는 핵심 기술 중 하나입니다. 38쪽 좋은 아키텍트는 사례르 통해 팀을 이끌어야 합니다. 아키텍트는 네트워크를 설치하고 빌드 프로세스를 설정하는 것에서부터 단위 테스트를 작성하고 벤치마킹을 수행하는 것까지 자신의 팀 내 어떠한 역할도 수행할수 있어야 합니다. … 훌륭한 아키텍트는 문제를 찾아내어 팀을 소집하고, 희생자를 지적해내지 않고, 무엇이 문제인지 설명하고, 정교한 대안이나 해결책을 제시할 수 있어야 합니다.

인간, 조직, 권력 그리고 어느 SW엔지니어의 변

인상 깊은 단락 p42 반면 소프트웨어의 경우는 소프트웨어 프로젝트마다 독특하며 이전 프로젝트에서 했던 것을 가져다 활요할 수 있는 것이 많지 않다. 덴버공항 수하물 처리 시스템이 그러 했다. 독일 스트라우스공항에서 수하물 처리 시스템을 만들었던 경험은 덴버공항 수하물 처리 시스템 개발에는 결정적인 도움이 되지 않았다. p237 고객이 요청한 것 하나를 들어주면 우리는 다른 서비스나 기능 하나를 제거해야 한다. 이렇게 해야 고객의 요청을 부담 없이 처리하면서 다른 부담스러운 일을 제거할 수 있다.

프로그래머가 몰랐던 멀티코어 CPU 이야기

인상적인 부분 p17 손톱만한 칩에 적용된 알고리즘이나 수천만명이 접속해서 보는 비디오 서버를 움직이는 알고리즘은 본질적으로 같다. p19 1990년대만 해도 2010년이 되면 클록 속드 10GHZ의 프로세서가 등장할 것이라고 예상했다.

시지프스를 다시 생각하다

시지프스를 다시 생각하다 : 어느 개발자의 직장 생활에 대한 보고서 인상 깊은 단락 p86 3M이 식스시그마를 도입하자 가시적인 지표는 개선되었지만 매출에서 신제품이 차지하는 비율이 줄어들었음.

맨먼스 미신

감상 ‘스캐폴딩 형태 중 하나로 더미 컴포넌트가 있다. 이것은 오직 인터페이스와 약간의 가짜 데이터 또는 몇개의 작은 테스트 케이스 등으로 구성된다.” 이 책이 몇년도에 나왔더라? 아뭏든 Unit Test나 Mock은 새로운 것도, 일시적인 유행도 아니다.

Refactoring Database

인상깊은 부분 p16 디자인은 한번 굳어버리는 순간 바로 구식이 된다 -프레드브룩스 p81 테이블이 사용 중일 때는 위험을 최소화하기 위해 컬럼 제거에 대한 시간 계획이 필요하다. 다른 방법으로는 ALTER TABLE 명령의 SET UNUSED 옵션을 이용하여 컬럼을 사용되지 않는 컬럼으로 표기하는 것이다. SET UNUSED 명령은 보다 빠를 뿐만 아니라 위험을 최소화할 수 있다. p205 데이터 마이그레이션 기법 : 오라클의 SQLLDR이나 bul loader와 같은 데이터베이스 유틸리티를 이용할 수 있다.

컨설팅의 비밀

인상 깊은 단락 p67 p187 p235 p254 p300 p309

XUnit Test Patterns

생각 메모 체계적으로 잘 정리되어 있으나, 책 두께에 비하면 핵심은 많지는 않음 많은 용어가 경험있는 사람에게는 섬세한 구분으로 와 닿을듯하나, 그렇지 않은 사람에게는 부담이 될 수도 있을듯 관련 링크 http://xunitpatterns.com/ https://martinfowler.com/bliki/TestDouble.html 정리 Fixture : SUT(System under test)를 실행하기 위해 필요한 모든 것 픽스처를 설치하기 위해 호출하는 테스트 로직부분 setup : 테스트 대상 시스템(SUT)에서 원하는 로직을 실행시키기 위해 설치해야 하는 테스트 선조건, 모든 객체와 객체의 상태 뒷문설치 공유 픽스처 신선한 픽스쳐(Fresh Fixture).

소프트웨어 개발의 모든 것

감상 XP모델의 단점으로 ‘우주 탐사선과 같이 테스트가 어려운 프로젝트의 경우에는 사용이 불가능하다'라… 이 책의 저자는 TDD를 하려면 우주선 띄워서 테스트라도 해야하는 것으로 이해하신듯 하다. 책 제목이 좀 더 소박했으면 사람들이 기대치를 낮추었을텐데..

꾸준히 자유롭게 즐겁게

http://osdi.insightbook.co.kr/ 인상깊은 부분 25쪽 커널 관점에서는 특정 태스크나 워크로드에서 0.5~1% 아끼는 게 전체적인 면에서는 그다지 중요하지 않습니다. 커널 개발 프로젝트 입장에서는 그렇게 아끼는 것보다 장기적으로 봤을 때 코드가 관리, 지속 가능하고 장기 목표를 얼마나 잘 성취할 수 있을까 하는 것이 중요하죠. 아껴서 돈을 버는 게 아니라 프로젝트를 건강하게 오래 유지하는 것이 목표니까요. 서로 목표가 다른 것이라고 볼 수 있습니다. 서비스 제공사는 서비스 개선에 우선순위를 두고 개발하는 것이 중요하지만 저는 아무래도 업스트림 커널 개발자이다 보니 장기적인 목표에 관심이 더 많았습니다.

.NET 예제로 배우는 단위 테스트

인상 깊은 단락 p274 동적언어에서의 테스트 용이성에 대해

알짜만 골라 배우는 구글앱엔진

감상 다양한 주제(특히 GWT)를 다룬 점과 예제를 모두 돌려보고 정리한 역자의 역할이 돋보인다. 그런데 getter/setter까지 굳이 다 인쇄하고, 개선이 가능해보이는 예제코드는 다소 아쉬운 점이 남는다. 보면서 따라서 입력해보고 스스로 개선해보라는 의도였을지도..

프로그래머의 길, 멘토에게 묻다

감상 개인적인 성장을 위해서 팀이나 고객을 이용하려 하기보다 공동체의 다양한 관심사를 기꺼이 더 우선시하는 것은, 장인 정신에 바탕한 접근 방식의 특징적인 면 중 하나이다” 개발자로서의 명예욕구가 큰 사람이 팀과 잘 조화를 이루지 못하는 경우를 보기도해서, 눈에 띄는 문구 인상 깊은 부분 p67 시간이 지남에 따라 이런 벤더 테스트 코드는 라이브러리를 최신 버전으로 업그레이드 했을 때 시스템에 문제를 발생시키는지 검사하는 용도로도 쓸 수 있다. p71 http://erlangish.blogspot.com/2007/05/shape-of-your-mind.html 의 내용 프로그래밍 언어가 미치는 영향성.

하드코드(Hard code)

인상깊은 내용 36쪽 번다운 차트 사용 38쪽 또 다른 위험은 ‘자원 안배를 잘 못해서 잃어버리는 시간'이다. 어려운 문제인 줄 정작알았더라면 개발자를 두세 명 더 투입하거나 선임 개발자를 붙였을 게다. 팀원들이 프로젝트 위험을 줄이려고 노력하기보다 기능 날짜를 맞추는데만 급급하다면 프로젝트는 그만큼 소중한 시간을 잃는다. 40쪽 기존공학이 수백 아니 수천 년에 걸쳐 쌓아온 경험적 예측성을 소프트웨어 공학에서 기대해서는 안된다. 42쪽 기능 완료일을 맞추라고 팀을 닦달하면 팀은 편법으로날짜를 맞추거나 거짓말을 둘러댄다.

토비의 스프링 3/3.1

감상 Java의 기초를 테스트코드로 설명한 Agile Java를 보고, 프레임웍도 그렇게 설명했으면 좋겠다고 생각했었는데,Toby님의 책이 그러한듯하다. testability, 좋은 설계 같은 핵심은 시간이 지나도 빛이 바래지 않을 것이고, 최신버전은 오히려 부차적 것일지도 감상2 (2012/11/25 추가) 아래는 일민형의 부탁으로 토비의 스프링 3.1에 들어간 추천사 토비님의 블로그를 통해 이 책의 집필 소식을 알게 되었고, 출판을 오랫동안 기다렸었다. 마지막까지 인쇄 사고로 배송이 지연되는애 태우는 일정 끝에 책을 받아들고는 비싼 전자기기를 산 기분보다 더 뿌듯했었다. 책을 받은 다음날부터 무거운 책을 출퇴근길에 들고 다니면서 완독을 했었다.

테스트 주도 개발: 고품질 쾌속개발을 위한 TDD 실천법과 도구

감상 2010.06.20 만일 당신이 때때로 실패하지 않는다면, 그건 안이하게 살고 있다는 확실한 증거다. -우디앨런 JUnit, Mock 라이브러리 등에 대한 최신 설명이 잘 정리되어 있다. 내년도 신입사원 교육도 내가 하게 된다면, 이 책을 참고도서로 강추할 예정. 인상 깊은 단락 p98 JUnit 탄생 일화 p249 Mock 프레임워크 트렌드 p321 실패라는 건 없다. 모든 건 피브백일 뿐이다. - 로버트 알렌 p446 SI에서 TDD

웹이후의 세계

감상 2010-06-05 ‘위피'의무 탑재가 폐지된 것이 불과 2009년4월이였다니.. 결국 혁신은 정책에 의해 하사되지 않았고, 시장경제의 압력을 타고 유입되었다. 밖에서는 의미없는 국지적 아류작이 될 수밖에 없는 ‘우리만의 플랫폼'의 한계. 여기서 교훈을 얻을 수 있는 사람들이 더 많았으면. 2010-02-10 어제 Adobe 세미나 때문에 생각나서 이 책의 2장을 다시 펴봤다. 실버라이드, 닷넷 서버프레임웍, 윈도우즈 OS, WPE 등까지 모든 스택을 다 가지고 있는 MS와 대응하는 스택을 제시하려면, Adobe는 Java 기술들과 계속 친하게 지내야 할듯하다.

세상을 뒤흔든 프로그래머들의 비밀

감상 “그저 테스트를 먼저 작성하지 않고서는 코드를 생성할 수 없습니다…프로토타이핑 중이든 가볍게 시험삼아 무언가를 작성하든 관계없이 무조건 테스트를 먼저만들 것입니다. 이 방법이 현재의 저에게는 더 빠른 방법이니까요” 로드존슨은 강한 TDD 원칙주의자 인듯..

Software Architecture In Practice 2nd Edition

감상 몇년전에 이 책을 봤을 때에는 ‘상식적인 내용을 체계적으로 잘 정리했군’ 정도로 큰 감흥이 없었다. 그런데 상식이라고 생각한 것을 결론으로 내든 근거로 쓰든 간에, 여러 상식을 묶어서 다른 이를 설득하려면 체계성이 가장 중요하다는 것을 이제서야 조금 깨닳은 듯 하다.

프로젝트가 서쪽으로 간 까닭은?

감상 모든 설계 결정을 내리는 영웅이나, 모든 요구사항을 결정하는 영웅이나, 모든 아키텍처 결정을 내리는 영웅이 바로 병목을 일으키는 원인이다 최근 ‘지나친 의욕은 민폐를 불러일으킨다'라는 말이 몇번 떠올랐는데, 일맥상통하는 내용이로군. 흔히 프로세스 개선 그룹, 표준 제정 그룹, 품질 부서 등이 업무 프로세스나 수행방식을 명시한다. … 대개 그들은 업무를 제대로 이해하지도 못하면서 업무 방식을 정해주는 외부인에 불과하다 그래서 현실감 떨어지는 프로세스 제정은 민폐에 불과하다. 침묵은 동의를 의미하므로, 침묵하는 전문가는 권위 없는 관리자 못지 않게 잘못된 결정에 책임을 져야한다.

엔터프라이즈 SOA

감상 SOA는 구체적인 기술이 아니라, 구조를 의미한다. SOA를 하기 위해서 꼭 특정기술을 써야한다는 주장만이 들리고 있고, 다른 선택을 말할 수 없는 상황이라면, 시스템의 이해관계자 중 솔류션 벤더사나 개발 조직의 이익만이 정치적으로 관철되어 있는 상황이 아닐까? 인상깊은 부분 20쪽 SOA는 엔터프라이즈 기술 표준이 아니다. 이는 SOA가 IIOP나 SOAP 같은 트정 단일 기술 프로토콜에 의존적이지 않다는 것을 의미한다. 대신 SOA는 아키텍처 청사진을 뜻하여, 이는 많은 상이한 기술들을 통합할 수 있고, 특정 프로토콜이나 연계기술을 요구하지 않는다는 것을 의미한다.

Expert One-on-One J2EE Design and Development

감상 시간이 지나서 다소 빛이 바랜 내용도 있지만, 이 책이 2002년도에, 그것도 당시 32살정도였던 사람이 썼다니 감탄이 나올 뿐이다. 인상 깊은 단락 p120 Strictly seaping, this is a special case of the Strategy design pattern: it appears different because the interfaces involved are so simple. )

능률적인 프로그래머

소개된 도구 https://gant.github.io/ http://schemaspy.sourceforge.net/ http://www.jroller.com/pulse/entry/getting_started_with_pulse : 개발환경 동기회 Eclipse plugin. 지금은 사라진듯. 인상깊은 부분 53쪽 하지만 일반 사용자에겐 편한 환경에 파워 유저의 능률은 오히려 떨어뜨린다. .. 지난 20년간 있었던 가장 기막힌 변화 중 하나는 파워유저의 단순 반복 작업 처리 속도가 오히려 느려진 점이다. 예전 유닉스 상요자가 이보다 훨씬 효율적이었던 이유는 모두 자동화했기 때문이다. 138쪽 오버엔지니어링 사례 : EJB, JSF

누워서 읽는 알고리즘

인상 깊은 단락 p27 빨간눈 승려 문제 p57 폰 노이만 일화 p59 1~100중 하나의 숫자가 남았을때 남은 숫자 확인 p60 하지만 회사에서 프로젝트를 수행하면서 느낀 점은 프로그래밍은 혼자서 하는 바둑이나 테니스 같은 게임이 아니라 팀이 단결해서 호흡을 맞추어야하는 축구에 더 가깝다는 사실이었다. p67 196문제 p69 역사는 정해진 길만을 가기 위해서 다람쥐 같은 삶을 반복하는 사람들이 아니라 아무 것도 정해지지 않은 미지의 세계에 자신의 삶을 던지는 용기 있는 사람들에 의해서 쓰여진다.

임베디드 C를 위한 TDD

인상깊은 부분 많은 C개발자들이 플랫폼마다 달라지는 코드를 처리할때 조건부 컴파일을 이용한다. 나는 여러분에게 조건부 컴파일을 피하라고 제안한다. 코드를 지저분하게 만들기 때문이다. 또한 특정 상황에서 어떤 코드가 실제로 컴파일 되는지 알아보기도 힘들다. (중략) 플랫폼마다 따로 구현될 함수들의 프로토타입을 정의하는 헤더 파일을 만들었다. 그런 다음 각 플랫폼 구현을 해당 디렉터리에 넣어서 분리시켰다. 우리는 전처리기 대신에 컴파일러와 링커를 사용했다.’ 추천사 … 이 책 ‘임베디드 C를 위한 TDD'는 기존의'코딩 많이 하고 디버깅 시작하기’ 식의 개발 방법과 TDD가 어떻게 다른지 본질적인 차리를 잘 보여준다.

실전 OSGI & Sprig DM

인상싶은 내용 39쪽 클래스 로더의 동작이 설명된 JLS http://durl.kr/gsb , http://durl.kr/gsc 124쪽 slf4j의 Parameterized logging이 30배 이상 빠르다는 설명 178쪽 String을 enum에 매핑해서 Switch문을 쓴 트릭 : http://sorcerers-tower.net/articles/switch_on_string_in_java

겸손한 개발자가 만든 거만한 소프트웨어

인상 깊은 단락 p42 멜빈 콘웨이 (Melvin Conway) 는 168년 데이터메이션(Datamation)지에서 이렇게 설명했습니다. “시스템을 설계하는 조직들은 자신들의 조직 사이에 의사소통 구조(communication structure)를 모방한 형태의 설계를 만든다. 이것은 콘웨이 법칙(Conway’s law)이라고 합니다. 예를 들자면, ‘네 개의 팀이 하나의 컴파일에서 작업할 때, 2단계(four-pass) 컴파일럴르 얻는 것'이 바로 대표적인 콘웨이 법칙입니다. p128 이렇듯 맛없는 개떡을 먹을 때보다 더 고약한 경험인 남이 만든 방법론을 맹목적으로 따를 때, 구성원 에게서 ‘책임감의 부재’ ‘동기부여의 상실’ ‘악의적인 순응'이라는 문제가 발생한다고 하니다.

Head First Software Development

인상 싶은 부분 Chapter 9 마지막 (번역판 p386) 개발을 일찍 끝낸 사람들을 벌하지 마세요. 그 사람들이 만든 것이 잘 실행된다면, 그들이 남은 시간에 다른 것을 미리 살펴보거나 새로운 무엇인가를 배울 수 있게끔 도와주세요.

Head First Object Oriented Analysis & Design

인상 싶은 부분 Chapter 2 (번역판 p109) 유즈케이스는 새로 만든 시스템이나 소프트웨어 변경 사항에 대한 요구사항을 찾아내는 방법입니다. 각 유즈케이스는 특정목표를 달성하기 위해 시스템이 사용자 또는 다른 시스템과 어떻게 상호작용하는지를 전달하는 하나 이상의 시나리오를 제공합니다.

프로그래밍은 상상이다

참고 5장 내용은 http://www.hanbit.co.kr/web/example/1594/progimagine_chapter5.pdf 에 인상깊은 부분 p124 충분히 무르익은 기술은 눈에 보이지 않게 된다는 아서 클라크(Arthur C. Clark)의 말처럼 컴퓨터의 물리적 존재는 점점 우리의 논앞에서 사라지고 있다. p184 미국에서 대학원을 다니던 시절에 잠깐 용돈을 벌기 위해서 심리학과 교수의 ‘인터뷰 자료 수집 프로그램'을 비주얼베이식으로 작성해준 적이 있는데, 내가 만들어 놓은 프로그램을 보고 심리학과 학생이 비슷한 프로그램을 금방 작성했던 것이 기억난다. p259 시간이 부족하다는 변명과 유닛테스트라는 개념에 대한 혼동은 확실히 취향의 문제가 아니라 수준의 문제이다.

소프트웨어, 누가 이렇게 개떡 같이 만든거야

29 스포츠 기자였던 레드 스미스(Red Smith 1906~1982)는 “글쓰는 것은 쉽다. 그저 혈관을 열고 피를 흘리면 된다.“고 말하기를 좋아했습니다. 126 브루스 슈나이더의 말 “기술이 보안 문제를 해결할 수 있다고 생각한다면, 문제도, 기술 자체도 이해하지 못한 것입니다.” 339 포넬리의 법칙 - 예제는 아무리 많아도 지나치지 않다. 341 인류학자인 마가렛 미드(Margaret Mead, 1901 ~ 1978)가 “사려 깊고 헌신적인 작은 그룹의 시민이 세상을 바꿀 수 있음을 절대 의심하지 말라. 실로 세상을 바꾼 것은 그런 소그룹뿐이었다.

지속적인 통합

지속적인 통합: 소프트웨어 품질을 높이고 위험을 줄이기 인상 깊은 단락 47쪽 품질이란 누가 보지 않을 떄에도 제대로 돌아가는 걸 뜻한다. 137쪽 테스트 분류 단위테스트 컴포넌트 테스트 시스템 테스트: JWebUnit 처럼 기능테스트(=인수테스트) : 실제 브라우저 사용 JWebUnit 예제 156쪽 테스트 케이스 하나에 ASSERT 하나로 제한하기 167쪽 수년간 이 메트릭에 대해 다양한 연구를 했는데, 10보다 큰 CCN을 가진 메서드는 같은 코드의 다른 코드보다 결함이 발생할 위험이 크다는 게 밝혀졌습니다.

자바 성능을 결정짓는 코딩 습관과 튜닝 이야기

인상싶은 내용 185쪽 로거에서 메서드 정보 등을 알아내기 위해 일부러 예외를 던지는 기법 241쪽 Apache Httpd의 ThreadsPerChild 273쪽 JMX를 쓸 때 별도의 파일로 id,pw를 지정하는 방법 282쪽 웹로그 분석툴 http://www.awstats.org/ 323쪽 JDK의 -Xss 옵션 : 스레드 스택 크기

켄트 벡의 구현 패턴

정리 55쪽 한정적 하위 클래스 이름 … 이 경우에도 결국 간결성과 풍부한 표현성 사이의 고민이다. 101쪽 따라서 타핑이 쉬운 쪽보다는 읽기 쉬운 쪽이 좋다. … 역할 제시형 작명 … 컴파일러에 이미 타입 정보를 알려줬는데, 그 정보를 다시 변수 이름에 포함해서 무엇을 얻을 수 있단 말인가? 117쪽 보호절 128쪽 (메서드) 의도 제시형 이름 Customer.linearCustomerSearch(String id) -> Customer.find(String id)

Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

http://www.yes24.com/Goods/FTGoodsView.aspx?goodsNo=2657930&CategoryNumber=001001003005006001 감상 2007.10.22 마이크로소프트웨어지에 ‘커뮤니티 노트'라는 컬럼을 연재하고 계신 최재훈님이 번역하신 책입니다. 사실 처음 책의 목차만을 보았을 때는 ‘실용주의 프로그래머'와 겹쳐지는 내용이 많을 것 같은 느낌에 큰 기대를 하지는 않고 읽기 시작했었습니다. 아마 제가 블로그를 통해서 이 책을 알지 못하고 서점에서 우연찮게 만났다면 책을 안 사고 지나쳤을 수도 있었을 것입니다. 그런데 다 읽고나니 다음에 프로젝트 시작할 때는 사비로라도 이 책을 사서 프로젝트 팀원들에게 돌리고 싶다는 생각이 들더군요. 이 책에서는 프로젝트를 성공적으로 이끄는 해결책으로 다음의 방법들을 제시하고 있습니다.

똑똑하고 100배 일 잘하는 개발자 모시기

인상 깊은 단락 p158 https://www.joelonsoftware.com/2005/12/29/the-perils-of-javaschools-2/ p175 지식산업 분야의 성과 특정의 어려움

Code completed 2nd Edtion

인상적인 내용 구현이 연구자와 필자들에게 경시되어온 또 다른 이유는, 다른 소프트웨어 개발활동과 비교했을 때 구현은 상대적으로 기계적인 과정이며 개선의 여지가 없다는 잘못된 생각 때문이다. 이는 사실과 완전히 다르다. 예술 비평가들이 모이면 그들은 형태와 구조, 그리고 의미에 대해 이야기를 나눈다. 하지만 예술가들이 모이면 그들은 값 싼 테레빈유를 어디서 살 수 있는지에 대해 이야기를 나눈다. 만약 6살짜리 꼬마에게 설명할수 없다면, 이해한다고 볼 수 없다.

Java puzzlers

인상싶은 내용 puzzle 57 (141쪽) hashCode() 미구현 사례 puzzle 61 (151쪽) Calendar 클래스의 월지정 실수 puzzle 62(155쪽) String 상수와 IdentityHashMap을 쓸 때의 문제 puzzle 68(172쪽) 변수와 타입이 같은 이름을 갖고 있고, 이 둘이 같은 영역에 있을 때는 변수 이름의 우선 순위가 높다. 비슷하게 변수와 타입의 일므을 패키지 이름을 가릴 수 있다. 상수 이름과 클래스 이름 간의 충돌을 방지하기 위해서는, 클래스 이름을 지을 떄 약어를 보통 단어처럼 취급하는 것이 좋다. [EJ Item 38].

당신은 웹2.0 개발자입니까?

최고의 웹2.0 사이트인 플리커의 수석 개발자 칼 헨더슨은 30분마다 수정사항을 사이트에 반영한다고 말했다.

실천가를 위한 실용주의 프로젝트 관리

인상 깊은 단락 p53 업무의 구분 프로젝트 업무 임시 업무 지속 업무 정기 업무 관리 p83 사람은 한 번에 한 프로젝트에 배치하세요 p89 팀과 부서의 차이 일반적으로 작다. 즉 다섯명에서열 명의 구성원으로 이뤄진다. 공동의 목적이나 목표가 있다. 일 처리시 서로 합의한 접근 방식이 있다. 서로 보완하는 능력이 있다. 상호 관련되거나 서로 독립적인 임시 목표가 있다. 서로에게 넘겨줄 작업을 약속한다. p200 효과적인 피드백을 위한 지침.

소프트웨어 컨플릭트 2.0

원서 : https://www.amazon.com/Software-Conflict-2-0-Science-Engineering-ebook/dp/B002GYWP1K/ 인상 깊은 단락 p19 업계 실무에서 최고 수준과 평균 수준이 이렇게 차이가 나는 분야는 거의 없다. p37 설계의 핵심 요소는 해결책을 제안하고 실패를 허용하는 능력이다. 성공하려면 실패하는 능력과 실패를 극복하는 능력이 필수적이다. p40 ‘The Mythical Man Month'와 최근 ‘Sillver Bullet’ 논문에서 프레드 브룩스는 현존 최고 제품, 즉 개념적 일관성이 있다고 우리 모두가 인정하는 작품은 개인이 설계한 작품이라는 사실을 지적한다. p41 설계 수행 면에서, 설계자는 기존에 생각하던 설계 본질이 틀렸다는 사실을, 오히려 시행착오를 거쳐가며 반복하던 엉성한 절차가 바로 설계 핵심이란느 사실을 이해해야한다.

웹2.0 경제학

http://www.yes24.com/Product/Goods/2156349 인상 깊은 단락 p121

소프트웨어 공학의 사실과 오해

http://www.yes24.com/Product/Goods/1418676?OzSrank=1 인상 깊은 단락 p24 저자의 화려한 경력 p29 많은 프로젝트의 성공과 실패는 어떻게 수행하는가보다 누가 수행하는가에 따라 결정된다. p31 사람 경시 풍조 사람은 빡빡한 스케쥴과 압박 하에서 일을 더 잘 한다고 주장한다. p33 잃어버린 곳이 아닌 밝은 곳에서 물건 찾기 일화 소프트웨어 분야에 있는 우리는 모두 마음속으로는 기술자라고 생각하며, 우리의 작업을 쉽게 하는 새로운 기술을 고안하는 것을 더 좋아한다. 마음속 깊은 곳에서는 사람과 관련된 문제가 더 중요하다는 것을 알면서도 말이다.

프리팩토링

http://www.yes24.com/Product/Goods/2160417 프리팩토링: 효과적인 시스템 설계와 변경을 위한 프리팩토링 지침 65가지 인상 깊은 단락 94쪽 테스트될 수 없다면, 요구하지도 말라. 128쪽 간단한 일을 잘하면 자주 불릴 것이다. 특정한 일을 수행하는 메서드가 클래스가 더 자주 재사용될수 있다. 151쪽 많은 원칙들을 생략할 수록 목표를 좀더 빨리 달성할 수 있을 것이라는 착각에 빠지게 된다. 이는 더 많은 코드를 작성하려고 먹는 시간을 줄이는 것과는 다르다. 먹지 않으면 결국 나중에 후회하게 될 것이다.

자바 병렬 프로그래밍

인상깊은 부분 73쪽 특정 변수를 선언할 때 volatile 키워드를 지정하면, 컴파일러와 런타임 모두 ‘이 변수는 공유해 사용하고, 따라서 실행 순서를 재배치해서는 안된다'고 이해한다. volatile로 지정된 변수는 프로세서의 레지스터에 캐쉬되지도 않고, 프로세서 외부의 캐시에도 들어가지 않기 떄문에 volatile 변수의 값을 읽으면 항상 다른 스레드가 보관해둔 최신의 값을 읽어갈 수 있다. 205쪽 더군다나 자바에는 스레드가 가업을 실행하고 있을때 강제로 멈추도록 하는 방법이 없다. 210쪽 스태틱으로 선언된 interrupted 메서드를 호출하면 현재 스레드의 인터럽트 상태를 해제하고, 해제학 이지너의 값이 무엇이썼는지를 알려준다.

실용주의 프로그래머

인상깊은 부분 385쪽 역자주: 사실 국어 실력과 프로그래밍 실력 사이에는 깊은 관련이 있다. 484쪽 해당 영역에서 개인 퍼포먼스의 최고 수중는 경험을 오래했다고 해서 자동으로 획득되지 않을뿐 아니라, 개선하려는 의도적 노력의 결과로서 가능하며, 심지어 매우 경험이 많은 개인들조차도 자신의 퍼포머스 레벨을 높일 수 있다.

Refactoring

인상깊은 부분 113쪽 리팩토링을 하지 않을 때에도 잘 짜여진 테스트는 프로그래밍을 빠르게 한다는 것을 알게 되었다. 122쪽 버그리포트를 받으면, ㅁ너저 그 버글르 밖으로 드러나게 할 수 있는 단위 테스트를 작성하라. 123쪽 완전한 테스트를 실행시키지 않는 것보다는 불완전한 테스트라도 작성하고 실행시키는 것이 더 낫다. ? 한 벌의 테스트는 버그를 찾는데 걸리는 시간을 엄청나게 단축시키는 강력한 버그 탐지기이다. ? 테스트로 모든 버그를 잡을 수 없다는 걱정 때문에 대부분의 버그를 잡을 수 있는 테스트를 작성하는 것을 멈추지 마라.

조엘 온 소프트웨어

인상 깊은 단락 31 지식노동자는 ‘무아지경'이라는 ‘흐름flow'에 빠져들어야 생산성을 최대로 발휘할수 있다는 사실을 우리 모두 잘 알고 있습니다. 101 게임회사의 출시일정. vaporware에 많이 올라와있음. 105 과업은 날짜 단위가 아니라 시간 단위로 측정할 수 있어야만 합니다. 125 스티브맥코넬이 일일 빌드에 대해 쓴 글 138 오픈소스의 사용성에 대한 글 링크 221 C에서의 상수 비교 습관. 조엘은 좋은 프로그래머의 습관이라고 생각함. 239 개발자는 멀티태스킹 기계가 아닙니다. 277 개발자 대부분은 바이트를 이동하는 대신에 API를 호출하는 방법으로 이 시대를 살아가고 있습니다.

테스트 주도 개발

인상 깊은 부분 25쪽 TDD란 프로그래밍 도중 내린 결정과 그 결정에 대한 피드백 사이의 간격을 인지하고, 또한 이 간격을 통제할 수 있게 해주는 기술을 말한다. “일주일간 종이에다 설계한 다음 코드를 테스트 주도로 개발한다면 이것도 TDD인가” 물론, TDD다. 결정과 그에 대한 피드백 사이의 간격을 인지하고, 또 의식적으로 제어했기 때문이다. 26쪽 동시성 테스트와 CSP 145쪽 TDD로 구현할 땐 테스트 코드이 줄 수와 모델 코드의 줄 수가 거의 비슷한 상태로 끝난다.

대한민국에서는 소프트웨어가 없다

http://www.yes24.com/Product/Goods/416619 인상 깊은 단락 156 이슈트래커, 버전관리 시스템의 중요성.

데드라인

인상 깊은 부분 49쪽 사람들은 안전하다고 느끼지 않는 한 변화를 수용하지 않는다. 62쪽 협박은 실적을 유도하기에는 불완전한 방법이다. 98쪽 최소한 단기간에 생산성을 높이기 위해서 할 수 있는 일은 사실상 아무것도 없기 때문에 제 생각에는 시간을 헛되게 쓰지 않도록 하는데 전적으로 맞추게 될 거에요 102쪽 생산성에 관한 단기적인 해결방법은 없다. 생산성 향상은 장기적인 투자의 결과다. 112쪽 프로젝트 초기에 잃어버린 한시간은 프로젝트 마지막에 잃어버린 하루와 같은 손실이 된다.

소프트웨어 장인정신

인상 깊은 단락 6쪽 소프트웨어 엔지니어링은 소프트웨어의 개발, 운영, 그리고 유지보수에 대한 체계적이고, 훈련되고, 측정 가능한 접근 방식의 애플리케이션이다. 즉, 소프트웨어에 대한 엔지니어링 애플리케이션이다. 18쪽 어쩋든 노동의 분할은 산업혁명의 기초였다. 더 작고 잘 정의된 작업으로 제조 활동을 나누는 것에 의해, 그룹의 생산성은 급격히 증가되었다. 물론 이 접근 방식은 소프트웨어 개발에도 적용될수 있을 것이다. … 그러나 그렇지 않다. 작업이 더 작은 단계로 세분화될수록, 한 사람에서 또 다른 사람으로 정보를 전달하는데에 더 많은 시간이 걸린다.

프로페셔널 소프트웨어 개발

인상싶은 내용 68쪽 “공학"의 사전적 의미는 수학의 원리와 과학을 응용하여 실세계의 문제를 해결하는 것이다. … 공학이 현실적이지 않다면 그것은 공학이 아니다. 75쪽 브룩스는 .. 소프트웨어 개발의 본질은 서로 맞물러 돌아가는 여러 컨셉들을 명세화하고 설계하며 검증하는 것이라고 주장했다. 또, 그는 솔프트웨어가 어려운 이유가 그 본질적인ㄴ 복작성, 일치성, 변화가능성, 비가시성 때문이라고 했다. 77쪽 그렇다면 1968년에는 변하지 않는 핵심(stable core)이 얼마나 있었을까? (별로 없었음)