簡評二十四

Why vendors perform code diagnostics before taking over an app developed by a third party

2 steps before taking over the code base

Codebase review
- is it complete (and matches the deployed version)
- does it have clear commit messages
- is it easy to setup the environment
Exploratory test
- find out bugs in the existing product
- understand what needs to be fixed, or what bugs existed prior to any new development work

Good to know how vendor take over an unknown code base.

CBT is the idea that our thoughts determine our emotions
- treat depression and other mental disorders
- used to overcome common challenges such as procrastination, perfectionism, or handling criticisms
Unhealthy thinking
- All-or-nothing think
- “Should” statement
  - We have a firm set of rules about how we should behave
  - Can motivate us, but often leave feelings of guilt, frustration, and failure
- Jumping to conclusions
  - Easily jump to negative conclusion
  - Examples:
    - Mind reading
      - arbitrarily conclude that someone is reacting negatively to you
    - The fortune teller error
      - you feel convinced that your prediction is an established fact
    - Catastrophizing / Magnifying or Minimizing
      - expect the worst to happen based on a slight incident that was not a big issue in the first place
    - Labelling
      - generalize one or two qualities into a negative global judgement

Should re-visit when we need to set up a better test enviornment

Cover unit test only
- thorough
- stable
- fast
- few
Too much (fragile) test can kill productivity
- Fixing test spent more time than implement feature
3 message origin (function call in other language)
- incoming ( being called )
- send to self ( private method )
- outgoing ( calling other)
2 message type
- query ( no side effect )
- command ( with side effect )
Incomming query message
- Assert return value
Incomming command message
- Assert side effect when it is accessable by public interface
Send to self
- Skip
  - we can test private function, if they save development cost (use TDD here)
  - - If private function tests fail, just delete them *
Outgoing query message
- Skip
  - It is redundent, as we have unit test on the message receiver already
Outgoing command message
- No mock -> integration test
  - We need integration test only if the function have side effects
- Mock message receiver -> unit test
  - Only need to test interface (only need to make sure the mocked object is used in correct way)
    - Can break the rule if side effect is stable an cheap
No testing principle can help if
- Interface is changed
  - - Program to Interface *

Be self-aware
- Taking care of yourself and paying attention to the way you feel
Timebox your frustration
Rubber-duck it
Draw it
Take five
- After you understand the problem, take a break
Ask for help
Isolate the problem
Ask the Internet
- Describe the problem and prepare code sample
- Find a friend to read what you write
- Ask for help on Internet
Find a workaround
Finally: Document the solution

The summary is good enough

In MongoDB, you may need to break a doucment into serveral and store them in different collection,
if the document is too large (> 16 MB).

Just some common sense on how to handle one/many to many relation in MongoDB.
I cannot find part II.

2 necessary but not sufficent condition

Talk about Base rate fallacy when mentioned in the book 「別掉入思考的陷阱」

Cloudfront RTMP CDN
Use Cloudfront as router
- Route to different website base on route
When cloudfront not ready, it will route to your S3 bucket
- What if you S3 have restricted connection?

Replace methods / attributes / functions at runtime, e.g. to stub out a function during testing;
Modify/extend behaviour of a third-party product without maintaining a private copy of the source code;
Apply a patch at runtime to the objects in memory, instead of the source code on disk;
Distribute security or behavioural fixes that live alongside the original source code (an example of this would be distributing the fix as a plugin for the Ruby on Rails platform).