|
|
Plan
From IdeA thinKING
Want to do
- Google Alert와 FaceBook 연결
- Ruby + GTK+ (with more friendly syntax)
- Google Streetview와 광고 관계
- Mobile에서도 광고가 될까?
- 어떤 정보도 저장할 수 있는 API가 제공되는 웹서비스 (Google Base?)
- Bug tracking system with Rails
- Reproduce steps
- Expected behavior
- Observed behavior
- Assigned to
- Whether it has been fixed or not
- (from The Joel Test)
- 이런게 있었네? http://16bugs.com/
- FaceBook WordPress plugin
- FaceBook Amazon wishlist application
- 이력 서비스 (Microformat, Facebook?)
- Micro payment (블로그의 정보에 대한 결제? - from 웹 2.0 경제학)
- (완료) Google Map과 TatterTools 또는 WordPress plugin 작성
- /cover 주소에서만 동작하도록
- API key 셋팅할 수 있도록
- (완료) Wordpress 플러그인 SVN에 등록하기
- Ruby의 metaprogramming을 이용한 UI 툴킷 만들어 보기
- LIFT에서 기억에 남는 내용들
- 나의 개인정보(디지털 정보뿐 아니라 atom이나 생각같은 것들까지)를 관리해주는 서비스
- Parallel universe - MMORPG에서 같은 세계의 동시인원수에 대한 한계 때문에 여러 개의 서버에서 같은 세계를 서비스한다. 단 다른 세계간에 상호 작용은 없다.
- Instanced dungeon - 하나의 동굴에서 많은 party들이 동시에 임무를 수행할 수 있도록 하기 위해 한 party마다 별도로 같은 dungeon을 제공한다.
- 건물들이 시시각각 용도가 달라진다. school on/off.
- BookCover 플러그인 개선
- 사이드바에 나오는 책들은 log로 관리하고 그 중 최신 몇개나 최근 몇개를 보여주도록 설정 가능하도록 개선
- 특정 페이지에 내가 읽은 책들을 소개할 수 있도록 관리
- Microformat 저장 사이트
- Simple FaceBook?
- CSS 제공
- 모바일 연동 (주소록)
- Greader나 Gmail의 star에 레벨 부여
Want to do
- MIT OCW
- Study group 참여/개설
- 클래식 음악
- 아일랜드의 역사
- 이스라엘과 중동의 역사
- autoconf
- 수학
- 다큐멘터리 제작
- 글쓰기
- LATEX
강의
Study 1
- Design Principle > Architecture > Design Pattern > Idiom
- Design Principle
- DRY, OCP, LSP(delegation, composition, aggregation), ISP, DIP
- Any Problem in Computer Science Can Be Solved with Another Layer of Indirection
- 버그의 수는 코드의 길이에 비례한다. 언어등과는 무관.
- OCP를 지키지 않으면 기능 추가시 기존의 코드가 변경되며 변경된 라인 그 자체뿐 아니라 변경된 코드가 있는 블록, 함수, 클래스등이 모두 잘못될 수 있으며 체크해야 할 코드가 길어진다.
- Schedule
- Design Principles
- Design Principles and Design Patterns
- Design Principles, Design Patterns and Refactoring
- TDD (Test Driven Development)
- Boost Library : smart_ptr, tuple, regex, function, bind, python, spirit, iterator
- It's your job to balance making sure the customer gets the functionality they want with making sure your code stays flexible and well-designed.
- The one constant in software development - CHANGE
- OO Principles
- Encapsulate what varies
- Code to an interface rather than to an implementation
- Each class in your application should have only one reason
- Classes are about behavior and functionality
- Using proven OO design principles results in more maintainable, flexible, and extensible software.
- 소프트웨어 품질의 잣대 (ities)
- 신뢰성 (reliability)
- 효율성 (efficiency)
- 인간 공학 (human engineering, readability)
- 이해 용이성 (understandability)
- 수정 용이성 (modifiability, maintainability)
- 테스트 용이성 (testability)
- 이식성 (portability)
- Symptons of poor design
- Rigidity - The design is hard to change.
- Fragility - The design is easy to break.
- Immobility - The design is hard to reuse.
- Viscosity(끈끈함, 점도) - It is hard to do the right thing.
- Needless complexity - Overdesign.
- Needless repetition - Mouse abuse.
- Opacity - Disorganized expression.
- OCP
- SRP
- Tom DeMarco and Meilir Page-Johns - Cohesion <-> coupling
- Each responsibility is an axis of change - orthogonal
- If a class has more than one responsibility, then the responsibility become coupled.
- In the context of the SRP, we define a responsibility to be "a reason for change."
- Belady and Lehman’s Laws:
- Software will continually change.
- Software will become increasingly unstructured as it is changed.
- Leveson’s Law:
- Introducing computers will not reduce personnel numbers or costs.
- Q1: OCP 같은 것을 사용하면 너무 클래스들이 많아져서 더 복잡해지는 것 같다.
- A1: 먼저 high cohesion, low coupling에서 high cohesion을 지키다 보면 실제 너무 많아지지는 않는 경향이 있다.
- A2: 많은 클래스에 있는 짧은 함수들과 하나의 클래스에 있는 긴 함수중 어떤게 좋을까? (물론 짧은게...)
- Q2: OCP나 DIP나 다 비슷한 것 같다.
- A1: 실제 Design Principles들은 서로 orthogonal하지 않다. 예제에서 봤듯이 DIP violation은 OCP violation을 유도하는 경향이 있고 DIP가 잘 되어 있다면 OCP를 만족시키기 쉬운 구조가 된다.
Study 2
- Good enough (예제로 Refactoring to patterns(RtP)에 있는 hello world 사용)
- 패턴에 익숙하지 않으면 더 복잡해 보인다. (RtP pp32)
- Architectural > Pattern > Idiom > Skill( == Idiom?)
- 우선 순위를 결정할 때는 risk가 큰 것부터.
- Test case 작성
- 요구 사항을 만족하는지에 대해 작성
- 기본적인 예외 사항에 대해 작성
- Code inspection이나 review에서 발견한 문제점 수정시 작성
- 실제 발견된 문제점 수정시 작성
- 툴 사용시 필요한 경우에만
- 그렇지 않으면 툴 때문에 해야 하는 성가신 작업이 생긴다.
- 실제 내가 어떻게 해야 할지 모르는 문제를 툴이 해결해줄 수는 없다.
- DOORS의 경우 backtracking이 가능하다고 하나 실제 규격에 맞게 문서를 작성하는 것이 더 힘들다. (물론 잘 사용할 경우엔 다른겠지만)
- Wiki나 blog가 대안?
- history가 저장된다.
- 최신 버전 유지가 쉽다.
- 이쁘다?
- 남에게 부끄럽지 않은 코딩을 하기
- 유행에 뒤쳐지지 않는 코딩을 하기
- The advantage of using objects is that I can define things that are responsible for themselves.
- A good design rule is that objects should be responsible for themselves and should have those responsibilities clearly defined.
- There are 3 different perspectives for looking at objects: conceptual, specification, and implementation.
- Expanding our horizons
- objects -- as a bundle of data and methods -- as things with responsibilities.
- encapsulation -- as hiding data -- as the ability to hide anything.
- inheritance -- for specialization and reuse -- as a method of classifying objects.
- containing variation of behaviors in objects.
- Two steps procedures of design process of the classes
- The relationship between the specification perspective and the conceptual perspective is this: It identifies the interface I need to use to handle all of the cases of this concept (that is, commonality).
- The relationship between the specification perspective and the implementation perspective is this: Given this specification, how can I implement this particular case (that is, variation).
- There are two basic strategies to follow in creating designs to deal with the variations:
- Find what varies and encapsulate it.
- Favor composition over inheritance.
- One way of measuring the quality of a design is to see how well it handles variation.
Study 3
- Refactoring
Study 4 or 5?
- UML 관련 내용
- C++ 관련 내용
- 클래스 읽는 법
- 생성자, 소멸자와 object의 lifetime.
- 상속과 생성자, 소멸자 순서
- 생성자의 초기화 리스트 수행 순서
- RAII (shared_ptr, deleter)
- Joel Test
|
