Productivity

나의 “생각저장소"를 이곳 Github Pages로 옮긴 이후, 몇 개의 더 글을 쓰면서 본격적으로 Jekyll, Markdown, 그리고 Liquid 이용한 정적 블로깅을 조금 더 경험해 봤다.
그 후 쓰게 된 이 글은, Jekyll의 성능에 대한 이야기이다.

몇 주 전 “블로그, Tistory로부터 Github Pages로 이주“라는 글을 통해서, “어떤 방식으로 Tistory로부터 Github Pages로 이사를 했는지“를 중심으로 기록을 남긴 바 있다. 이번에는 내 글들의 새 터를 “좀더 블로그답게 정비한” 이야기이다.

따지자면 5년 전에 적었던 “Jekyll로 github에 블로깅하기“의 2탄인 샘이고, 얼마 전, 좀 대충 적은 듯 한 “Setup Jekyll for Github Pages“와 함께 읽으면 Github Pages를 이용한 블로깅을 새로 시작하는 사람들에게는 그럭 저럭 읽어볼만한 “시작하기+@ Guide"가 될 수 있을 것이다.

얼마 전에 Ember.js와 Semantic-UI를 사용한 프로젝트를 진행하고 나서, 발표 초기에 얼마간 맛보기로만 사용해본 후 방치해오던 Github Pages를 다시 사용하는 것이 어떨까… 하는 생각을 하게 됐다. 그래서, 일단 2007년부터 2012년까지 사용하다가 역시 방치하고 있었던 Tistory의 글들을 여기로 옮겨왔다.
이 글은, 옮기기로 결정한 이유와 옮긴 과정, 그리고 그로 인한 변화를 담고 있다.

ㅋㅋㅋ

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. 스텐드 업 미팅을 사용하자.
39. 좋은 디자인은 활동적인 프로그래머로부터 진화한다.
40. 코드 공동 소유를 강조하자.
41. 멘토가 되자.
42. 다른 사람에게 문제를 해결할 기회를 주자.
43. 준비 되었을 때만 코드를 공유하라.
44. 모든 코드를 리뷰하자.
45. 다른 사람에게 계속해서 알리자.

간판 시스템(kanban; 일본식 발음, 도요타에서 유래했다나? )은 말하자면 일종의 “상황판"같은 것이다. 소프트웨어 개발의 관점에서 말하자면, 넓은 판에 개발의 각 단계를 영역으로 구분하여 표시한 후(고정된 말판), 접착식 메모지 등에 적은 개발 요건(말)을 그 위에서 개발 진척도에 따라 이동시킴으로써 전반적인 개발 진척도를 한 눈에 파악할 수 있도록 한 것. 또는 그 이상이라고 말할 수 있겠다. 마치, 윷놀이 하듯 개발을 한다는 얘기다. :-)

Kanban bootstrap | Lean Software Engineering

The goal of a kanban workflow system is to maximize the throughput of business-valued work orders into deployment. It achieves this by regulating the productivity of its component subprocesses.

[더 읽기]

현재 안랩코코넛의 대표이사이시며 IBM, 안철수연구소 등에서 22년간 IT 산업에 종사하셨다는 이정규님의 글.

ZDNet Korea…문서작성의 5가지 口訣

공공기관의 입찰 선정 심사위원으로 참여한 적이 몇 번 있었다. 내공이 있는 심사위원은 제출된 문서의 형식만 척 보아도, 업체의 역량을 가늠해 볼 수가 있다. 커버에 반드시 있어야 할 제목, 부제목, 작성일자, 작성자명, 작성자 이메일, 부서명, 회사명, 문서의 비밀등급을 제대로 기입하였다면 잘 된 문서이다. 특히, 문서의 파일명을 귀퉁이에 기재한 경우는 정보검색의 효율을 관리하고 있다는 반증이 된다. 요약문과 구조화된 목차, 흔히 오리발 조항이라는 disclaimer의 유무, 약자의 설명페이지가 있다면 외형적 형식은 아주 잘 되어 있는 것이다. 그러나, 품격 있는 문서는 그 이상이 필요하다.

[더 읽기]

“프랭클린 플래너는 비싸다.”,
“프랭클린 플래너를 사용하면 시간을 벌 수 있다.”,
“시간은 돈이다.”,
“프랭클린 플래너를 사용하면 돈을 벌 수 있다.”
그럼… 프랭클린 플래너는… 공짠가?

투자지 바보야!

lovesera.com : art of virtue :: [책] 프랭클린 플래너를 쓰는 사람의 시간은 다르다

가은오토파파의 결론

1. 우리는 시간을 관리할 수 없습니다. 다만 우리의 행동을 관리할 뿐입니다.
2. 이러한 행동관리는 인식의 문제가 아니라 실천의 문제 입니다.
3. 실천을 위해서는 내면의 소리에 귀 기울이고 진정한 자신의 역할을 찾아야 합니다.
4. 성공이란 결국 자신에게 주어지는 시간을 얼마나 잘 활용했냐에 달려 있습니다. 모든 이들에게 공평하게 배분되는 자원은 바로 시간입니다.
5. 프랭클린 플래너는 인간 관계를 만들어 가는 도구라 생각됩니다.
6. 진정한 통찰력의 힘은 경험을 바탕으로 한 독서에서 나온다고 확신합니다.