'Books'에 해당되는 글 18건
- 2011/12/01 [BOOKS] 처음 읽는 아프리카의 역사
- 2011/11/04 [BOOKS] 파인만 FYNMAN
- 2011/10/19 [BOOKS] 소프트웨어 크리에이티비티 2.0
- 2011/06/19 [책] Cocoa Programming: A Quick-Start Guide for Developers (Pragmatic Programmers)
- 2011/06/16 [책] Learn iPhone and iPad cocos2d Game Development 정리.
- 2011/05/24 [책] 실용주의 사고와 학습
- 2011/05/09 [책] 나는 세계일주로 경제를 배웠다
- 2011/04/19 [책] 플랫폼 전략 : 장(場)을 가진 자가 미래의 부를 지배한다
- 2011/04/14 [책] 너무 많이 알았던 사람 : 앨런 튜링과 컴퓨터의 발명
- 2011/04/06 Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드
"처음 읽는 아프리카의 역사"
재밌다.
지구의 첫 대륙이지만 유럽 열강들에게 인권을 유린당했고, 여전히 에이즈와 내전으로 고통받는 대륙.
한 장, 한 장 넘기면서 무섭기도 했고 슬프기도 하지만 앞으로 아프리카 르네상스가 다시 한번 찾아와주기를 바라게 되는 책.
아프리카에 대해 너무 무지해서 그런가 잘못 알고 있던 내용도 많았고,
내 시각을 교정할 수 있는 기회가 됐다.
단시간에 재밌게 읽었다.
아프리카에 손톱 만큼이라도 관심이 있다면 읽어보길 권한다.
파인만,,
원래 유명한 분의 일생을 만화책으로 만날 수 있다.
가장 기억에 남는 말은 파인만의 아버지가 어린 파인만에게 해 준
"게임을 즐기려면 먼저 규칙을 잘 알아야한다, 그리고 잘 살펴보면 규칙을 알 수 있단다." 는 말이다.
정확한 기억인지는 모르겠지만,, 하여간
게임을 즐기려면 규칙을 알아야하고 뭐든지 잘 살펴보다 보면 규칙을 알 수 있다는것에 동의!!
우리 아이들에게도 기회가 되면 해줘야지..^^;
일대기 책이 대부분 그렇듯이, 첨에 재밌고 중간에 지루하고, 나중에 약간 재밌으려 하다가 끝난다.
뭐 이 책도 그 범주를 벗어나지는 않는듯..
요즘 읽고 있는데, 재밌는 책이다.
좀 오래됐지만 에세이 형식으로 소프트웨어 프로젝트에 대한 여러가지 생각을 담고있다..
반정도 읽었는데,, 다 읽고 나면 정리해야겠다..
----------------------------------------------------------------------------------
다 읽어버렸다.
흠..
앞 부분에는 흥미로운 내용이 나오는데 중/후반부는 지루하다.
에초에 창의력은 개인의 능력+환경이 아니던가...
뭔가 있을꺼라는 막연한 기대감으로 시작했던것이 역시나,,, 로 끝나버렸다...
아쉽지만 그래도 몰랐던 역사와 학계 내부의 갈등, 현실과 실제 개발에서의 차이 등을 였볼 수 있어서 좋았다..
재밌는 내용을 책에 접어 놓았는데, 정리하기 귀찮아서 그냥 패스...
2011/06/19 10:49
[책] Cocoa Programming: A Quick-Start Guide for Developers (Pragmatic Programmers)
2011/06/19 10:49 in Books

이 책도 참 잘 만들어진 책인 것 같다.
Cocos2D를 사용한 프로젝트를 진행 중인데, 한번은 봐야겠다 싶어서 보는 책.
앞으로 챕터 별로 정리를 할 예정이다.
1장은 패스
2장. Getting Start.
- 설치 관련 부분은 패스
템플릿을 시작하고 실행하면 HelloWorld가 나타남
- 메모리관리
- autorelease를 많이 사용하고 있다
- 아이폰 스팩
- 시뮬레이터 관련 설명 - 여러가지 측정이 불가능하다 정도의 내용
- 3장 Essential
실용주의 프로그래머에 이어 읽고있는 "실용주의 사고와 학습"
뇌 얘기가 흥미롭네요.
재밌게 읽었습니다.
p156
지식을 경험 없이 그 자체로만 습득하는 것은 효과적이지 않습니다.
목표와 피드백 없이 무작위로 접근하게 되면 무작위적인 결과를 낳습니다.
p188
에자일 소프트웨어 개발의 교리 중 하나는 불필요한 문서화를 피하는 것.
문서를 위한 문서는 시간 낭비. -> 이런 문서는 나중에도 아무도 보지 않는다.
p199
새로운 것을 활용하거나 문제를 풀 때 재미있는 방법을 찾으면 더 즐겁게 할 수 있지만 더 배우기 쉽게 만들어주기도 합니다.
팅커토이(tingker-toy)나 레고 블록으로 시나리오를 실현해 보세요.
p262 효과적인 변화
1. 계획으로 시작하라.
2. 진짜 적은 실수하는 것이 아니라 아무것도 하지 않는 것이다.
3. 새로운 습관은 시간이 걸린다.
4. 믿으면 사실이 된다.
5. 작은 걸음으로 나아가라.
-----------------------------------------------------------------------
뇌 얘기가 흥미롭네요.
재밌게 읽었습니다.
p156
지식을 경험 없이 그 자체로만 습득하는 것은 효과적이지 않습니다.
목표와 피드백 없이 무작위로 접근하게 되면 무작위적인 결과를 낳습니다.
p188
에자일 소프트웨어 개발의 교리 중 하나는 불필요한 문서화를 피하는 것.
문서를 위한 문서는 시간 낭비. -> 이런 문서는 나중에도 아무도 보지 않는다.
p199
새로운 것을 활용하거나 문제를 풀 때 재미있는 방법을 찾으면 더 즐겁게 할 수 있지만 더 배우기 쉽게 만들어주기도 합니다.
팅커토이(tingker-toy)나 레고 블록으로 시나리오를 실현해 보세요.
p262 효과적인 변화
1. 계획으로 시작하라.
2. 진짜 적은 실수하는 것이 아니라 아무것도 하지 않는 것이다.
3. 새로운 습관은 시간이 걸린다.
4. 믿으면 사실이 된다.
5. 작은 걸음으로 나아가라.
-----------------------------------------------------------------------
사무실에 동료가 읽고있던 책을 빌렸다.
얼마전 일본 사건도 있고(일본에 지진이 나자마자 물을 대량으로 사재기 해서 일본에 파는 후배 녀석이 있었...ㅡ,.ㅡ)
가볍게 읽을 수 있는 경제 서적 인듯.

----
얼마전 일본 사건도 있고(일본에 지진이 나자마자 물을 대량으로 사재기 해서 일본에 파는 후배 녀석이 있었...ㅡ,.ㅡ)
가볍게 읽을 수 있는 경제 서적 인듯.
----
책이 얇고 한 페이지에 글자도 몇 개 안된다.
내 생각과 어떤 부분이 다른지 읽어보기로 했다.
------------------------------------------------------------------------------------->
다 읽었다!!
그리 새롭거나 한 내용은 없다. 정말 정보에 둔감한 사람이 아니라면 상식선에서 알고있는 내용들을 문서화 한 느낌.
딱히 추천도서는 아닌듯....
내 생각과 어떤 부분이 다른지 읽어보기로 했다.
------------------------------------------------------------------------------------->
다 읽었다!!
그리 새롭거나 한 내용은 없다. 정말 정보에 둔감한 사람이 아니라면 상식선에서 알고있는 내용들을 문서화 한 느낌.
딱히 추천도서는 아닌듯....
튜링이라면 그 유명한 튜링 머신의 튜링이 아닌가!!!
컴퓨터의 아버지이며 폰 노이만에 가려진 천제라 불리던 그 사람!
완전히 호기심으로 읽고 있다.
그런데 번역이 완전 실망이다.
그냥 고등학교 때 독해 공부할 때 느낌의 번역체...
그리고 쓸데없이 자꾸 문장 중간에 나타나는 고딕체가 책을 읽는 내내 거슬린다.
책의 내용을 더 혼란스럽게 만드는 번역체는 나로 하여금 같은 구절을 여러번 읽게 만든다.
앞으로 "승산" 출판사의 책들은 좀 피해야겠다...
---
뒤로 갈 수록 번역체는 좀 나아진다. -> 계속 읽다보니 번역체가 왔다갔다 한다....
--
다 읽었다!!
그런데 기대했던 것 보다는 위에 자질구래한 것들 때문에 내용이 잘 들어오지는 않았지만,,,
(아직도 여러번 읽어도 이해가 안가는 문장들이 몇 개 있다. 아우 ㅡ,.ㅡ )
튜링과 노이만, 에드박, 에드삭, 에니악 등 의 역사에 등장하는 재밌는 소재들이 등장하는 것은 나름 재밌었다.
노이만 방식을 빠르게 구현한 현대의 컴퓨터의 원류에 대해 진지하게 생각해 볼 기회가 됐다.
(튜링의 연구를 바탕으로 한 노이만 방식이라고 해야겠다 ㅋ)
오늘부터 읽기 시작한 책.

TBD(Tracer Bullet Development)를 실천하기 위한 책이라고 해서 읽어보려고 한다.
나의 기대를 저버리지 않았으면 좋겠다. -> 사실 읽고난 느낌은 기대를 채워주지는 못했다!!! -------------------------
팁 조언 요약
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. 동작하는 데모를 일찍 그리고 자주 전달하세요.
32. 여러분이 무엇을, 왜 하고 있는지 공개하세요.
33. 얼굴을 많이 마주칠 수록 팀워크가 단단해집니다.
34. 고쳐야 하는 것만 고치세요.
35. 파괴적인 '우수한 업무처리기법'은 진정한 의미의 업무처리기법이라 할 수 없습니다.
36. 밑에서부터 혁신해야 합니다.
37. 말만하지 말고 보여주세요.
38. 버그가 있는 곳을 테스트하세요.
40. 목록은 살아있는 문서입니다. 변화가 목록의 생명입니다.
41. 목록에 없다면, 그것은 프로젝트의 일부가 아닙니다.
42. 항상 피드백을 빨리 해주세요.
TBD(Tracer Bullet Development)를 실천하기 위한 책이라고 해서 읽어보려고 한다.
나의 기대를 저버리지 않았으면 좋겠다. -> 사실 읽고난 느낌은 기대를 채워주지는 못했다!!! -------------------------
팁 조언 요약
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. 동작하는 데모를 일찍 그리고 자주 전달하세요.
32. 여러분이 무엇을, 왜 하고 있는지 공개하세요.
33. 얼굴을 많이 마주칠 수록 팀워크가 단단해집니다.
34. 고쳐야 하는 것만 고치세요.
35. 파괴적인 '우수한 업무처리기법'은 진정한 의미의 업무처리기법이라 할 수 없습니다.
36. 밑에서부터 혁신해야 합니다.
37. 말만하지 말고 보여주세요.
38. 버그가 있는 곳을 테스트하세요.
40. 목록은 살아있는 문서입니다. 변화가 목록의 생명입니다.
41. 목록에 없다면, 그것은 프로젝트의 일부가 아닙니다.
42. 항상 피드백을 빨리 해주세요.
Prev
Rss Feed