一個運動記者追逐名利多年，得知以往嘅大學教授病重之後，就固定每星期二去探佢。本書就係講佢地最後十四個星期嘅對話。

Read More

講一D搞怪嘅心理學實驗，入面嘅實驗結果都反映左一D有趣嘅野

時間心理學

• 股市唔穩定時，短期投資求奇買可能賺得仲多
• 星座嘅設定反而影響左細路嘅個性
• 人寧可欺騙自己，也不願坦然面對自己容易受騙
  • 無意識中欺騙自己
• 只要占星家講得模糊諂媚，多數人會覺得準
• 心理因素影響壽命
  • 過節前死亡率較低
  • 男人生日前一周死亡率較高
    • 檢視人生，成就太少而受壓力
  • 樂觀比較長命

Read More

Six Strategies for Application Deployment

Recreate

• Version A is terminated then version B is rolled out.
• High down time
  Ramped (also known as rolling-update or incremental)
• Version B is slowly rolled out and replacing version A.
• Both new and old version exist during deployment, need to support multiple version at the same time
  Blue/Green
• Version B is released alongside version A, then the traffic is switched to version B.
  Canary
• Version B is released to a subset of users, then proceed to a full rollout.
• Usually used when low confidence on new release
  A/B testing
• Version B is released to a subset of users under specific condition.
• Requires intelligent load balancer
• Difficult to troubleshoot erros for a given session
  Shadow
• Version B receives real-world traffic alongside version A and doesn’t impact the response
• Can test system load
• Complex to set up, need to mock service

The Clean Code Talks – Unit Testing

Writing testable code is more important than writing good tests

• If the code is difficult to overwrite, then it will be difficult to test

  1. Main method in procedural program or static method in object oriented code is difficult to test
     • The dependency in main program cannot be mock
  2. Deep inheritance
     • The parent class cannot be mock, need to test all inheritance
       Purely procedural is hard to test, because it is difficult to isolate the logic. Procedual code difficult to overwrite.
       E.g main method is difficult to test

• Unit test should be done by the same developer

  • Test engineer is difficult to write good test on untestable code
  • Developer cannot get feedback on untestable code if they don’t write tests
• Writing testable code > writing good test

Read More

People losing ability to listen other. Pay attention instead of showing you are paying attention.

10 communication rules

1. Don’t mutlitask
2. 不要自以為是(Don’t pontificate)
   • always assume you can learn sth in communication
3. Use open end question
   • complex question will get simple answer
4. 順其自然
   • let go the new idea come in you brain
   • need to focus on the discussion
5. Say don’t know if you don’t
6. Don’t compare you exp with other
   • don’t tell your similar exp when other talking theirs
     • no experience are the same
     • don’t need to promote yourself during conversation
7. Don’t repeat yourself
8. Don’t need to mention the detail
   • they want to know what you like
   • what we have in common
9. Listen
10. 要精簡

Be interested in other people

• 內向 vs 外向
  • 獲取能量差異
    • 內向者需要抽離與安靜
    • 外向者需要從活動與他人的接觸
  • 內向同外向係一個連續譜系
    • 長時時超出自己嘅舒適區對健康有影響
  • 係內向同外向之間遊移係正常
    • 人會受到文化，情境，扮演嘅角色，年紀，心情而變動
  • 內向，害羞，高度敏感係三種冇直接關聯的特質
  • 內向唔係一個缺點
  • 對自己嘅需求越清楚，就能越輕鬆面對自己同其他人相處
• 內向者的長處
  • 謹慎，實在，專心，傾聽，平靜，擅長分析，獨立，穩定，書寫（取代談話），為人著想的能力
• 內向者的障礙
  • 恐懼，瑣碎，過度刺激，消極，逃避，過於尚智，自我否定，僵固，避免接觸，畏懼衝突

Read More

唔用錢過生活，以自己希望嘅服務去交換自己所需去過活。有D過份理想化，我唔覺得可以大規模進行。
曾成立交換中心，以點數代替金錢

• 以另一種價值去評價一個人嘅工作
• 點數會按時扣減，以鼓勵交換

以下係share左去facebook嘅article，係自己個blog 留個copy, 沉澱一下。

Something Slightly Less Terrible

Software product個nature好dynamic，冇所謂嘅perfect嘅code。唔同嘅technology，framework都係trade off。追求Technology本身冇咩意義，最重要係個product解決到問題，可以keep住maintain同run落去。

22 May 2018

Re-read, re-write comment and move comment into another article

Read More

TL;DR

Answer 1

• Deploy experimental feature on Friday, it crashes the whole system
  • Never put yourself in a position to make mistake
    • TDD
  • Not a good idea to deploy big stuff on Friday
  • Think about the risk before deploy
  • Confirm after deploy asap
  • Don’t be afraid to move fast and break things
    • Mistake make you grow

Short summary

We did everything he mentioned besides TDD, just keep it as a reminder.

Read More

Testability > Reusability when writing code.

Reviewed points

• Testability > Reusability
  • The cost to make a code reusable (general) enough is high
  • Actually what we want is modularity, high cohesion, low coupling
  • Very little code can be reuse four times, but we always need to test the code
    • Design the code for test is more practical than design for reuse
• When to reuse?
  • We still reuse the code if possible, but when?
  • Micro answer
    • Find module to use before coding a new one
    • Refactor the code to make it reusable after we reuse it 3 or 4 times
      • Refactor should be easy if the code is design for test
  • Macro answer
    • If the code widely reusable, make it as a library, a plugin or an application
      • Let market to decide the economics of reusability

Read More