#3 先衝再說

變成寫部落格網站多過於寫部落格了，但寫了部落格網站就沒有其他藉口可以不寫作了 ✏️

有趣的是

真的落地的 AR 應用

目前講到 AR 應用還不如 VR 來得廣泛，第一個想到的可能是 iOS 的 AR 模組，有時可以在螢幕上投影小動物在桌面上，另一個想到的就是 Microsoft 貴鬆鬆的 Hololens，以前有一次體驗運用 Hololens 來做到虛實協作的經驗，超級突破想像，但這些都不太能在平常生活中就可以使用。而 Laseros 透過投影技術，讓 AR 真的可以融入生活。

試玩看看

給我魚不如給我魚竿

大多數的理財服務都專注在預測跟提供標的，Projection Lab 更專注在視覺化你的財務分配會帶來的結果，有沙盒模式可以試玩不同人生階段有的現金流、並且可以拉時間軸看看人生轉變會有什麼結果，也可以安排不同的規劃（例如大約什麼時間點會花大錢）來看現金流會有什麼變化，初步接觸下來覺得可以真實了解資產配置的結果，是初衷很棒的產品，但相應的這麼抽象的規劃能不能刺激行為改變，就有待觀察 XD

試玩看看

讀了一些

心裡不安時可能會犯下的錯誤

激怒聰明員工的最佳方式這篇文章以詼諧的方式點出常常踩到的雷點：

• 不要讓需求曖昧不清：曖昧不清的需求會讓人發想爛點子，且草草讓其他人執行出現爛結果，這一切責無旁貸是出爛點子的人的錯，。
  • 取而代之請定義需求並轉換成文件，並列清楚：目的、需求細節（不是解決方法）跟 DoD 。
• 不要微管理：請不要無所不用其極的管別人要怎麼做的細節，拜託不要。
  • 取而代之的請瘋狂地問問題，並補充更多你知道的背景讓專業的人來幫你想辦法。
• 不要濫用權力：請不要濫用你職權上可以知道比較多事情，隱藏資訊藉此來說服別人，甚至讓所有決定都需要通過你，這樣會成為團隊瓶頸。
  • 取而代之的是成為推動事情的人，而不是因為有你才能把事情完成的人，可以參考另一篇文章： Operating well – what I learned at Stripe

閱讀文章

抽象原則實務運用在 React

Applying SOLID principles in React 這篇文章提供 SOLID 原則於 React 中的實務運用方式並提供非常詳細的案例：

• SRP 單一職責原則
  • useState + useEffect 的場合就很適合變成 customHook，甚至可以進一步將 api 取資料邏輯與 reducer 分開
  • 對沒有任何事件處理的 component 可以拆分成 pure component
  • 判斷邏輯可以抽成一個 utils
• OCP 開放封閉原則
  • 利用傳入 children 來調整，就不需要調整 parent component 內的邏輯。
• ISP 接口隔離原則
  • 在元件上 prop 應盡可能傳入最少資料
  • 如果今天遇到雷同的物件類型，但部分的欄位不同，可以透過 object key name in object 來進行判斷
• DIP 依賴反轉原則
  • 將常用的 api 邏輯抽離 component 改用傳入的。

閱讀文章

我也想要這樣上班 QQ

How to work flexibility 這部影片分享了 Gumroad 創辦人怎麼創造沒有死線、全遠端、兼職的工作環境，有很多寶可以挖，稍微記錄比較落地的知識管理架構 ：

• 入口 Flexile

  • Roadmap 清單與目標，目標下的子項目會各自對應一個 Page（通常只會有 1 季）
  • Icebox 過去完成的項目
  • 關於專案的背景資料
    • Memo: 記錄專案初衷、論述沿革的地方
    • Research: 使用者、市場研究結果
    • Customer Feedback: 客服回饋
    • Help Center: FAQ 記錄
    • Data: 數據資料
  • 子項目 Page
    • 屬性會有 github, figma 等連結
    • 所有討論會在 Notion 的 comment 中
    • What : 一句話摘要是做什麼
    • Engineer Note : 每一版 PR 大致希望做到什麼
    • Funtional Requirement : 類似 User Story 的內容，但會更接近 Spec
    • Resrouces : 其他 assets 資源
    • Pipeline : 實作到哪個階段（共用的流程）

• Roadmap : 會有兩季的規劃內容

• Internal Roadmap：雷同，但是可能是更行政層的，也包含怎麼調配 Roadmap 節奏的敘述

• People

  • 所有成員到職時間與工時
  • Onboard 的 template

• Wiki 所有資訊

• Home 導覽入口處

整體看下來，有適當的規格精度、使用者回饋的共識跟在 Refine 上預留更多時間與版本，是目前觀察下來得以成功的關鍵。Refine 從文件開始的 comment，設計稿到 PR 版本，是非常符合 MVP 的精神在做嘗試，覺得是很值得嘗試的團隊協作方式。

閱讀文章