# 學習目標
1. 前端遊戲頁面製作
- 了解PixiJS基本原理與操作
- 進行基本練習
- [ ] 圖片載入畫面
- [ ] 元件移動、旋轉、縮放控制
- [ ] 元件顯示、隱藏控制
- [ ] 點擊事件捕捉處理
- [ ] 如何產生特效
- [ ] 如何製作遊戲頁面素材
- [ ] 建立場景
- 了解開發工具使用
- [PixiJS Devtools](https://chrome.google.com/webstore/detail/pixijs-devtools/aamddddknhcagpehecnhphigffljadon)
- [框架Phaser(選配)](https://phaser.io/)
- 參考
- [官網](https://pixijs.com/)
- [教學](https://github.com/Zainking/learningPixi)
- [鐵人2018](https://ithelp.ithome.com.tw/users/20106532/ironman/1249)
- [鐵人2022](https://ithelp.ithome.com.tw/users/20152526/ironman/5741)
2. DDD相關
- Event Storming
- Context Mapping
- TDD(Test-Driven Development)
- [ ] 撰寫測試程式碼
- [ ] 在測試的保護下至少進行一次重構
- BDD(Behavior Driven Development)
- [ ] 進行example mapping
- [ ] 建立Scenario list
- ATDD(Acceptance Test-Driven Development)
- [ ] 建立user story
- [ ] 產出驗收測試文件
- 參考資料
- [Think in Domain-Driven Design(2019鐵人)](https://ithelp.ithome.com.tw/users/20111997/ironman/2730)
- [在 Ruby on Rails 中導入 Domain-Driven Design 是不是搞錯了什麼?(2021鐵人)](https://ithelp.ithome.com.tw/users/20108265/ironman/4846)
- [馬克的軟體架構小筆記(2021鐵人)](https://ithelp.ithome.com.tw/users/20089358/ironman/4359)
- [30天快速上手TDD](https://ithelp.ithome.com.tw/users/20010292/ironman/462)
3. TypeScript
- 熟悉TypeScript基本語法
- [ ] 了解interface並使用在程式中
- [ ] 了解class並使用在程式中
- [ ] 了解泛型<T>並使用在程式中
- [ ] 了解decorators並使用在程式中
- [ ] 了解modules並使用在程式中
- 了解TypeScript編譯器的運作方式
- 參考資料
- [TypeScript 新手指南](https://willh.gitbook.io/typescript-tutorial/)
5. 前端測試
- [學習使用Jest](https://jestjs.io/zh-Hans/)
- [ ] 安裝Jest
- [ ] 了解discribe(), test(), except()
- [ ] 斷言練習toBe, toMatch, toEqual, toContain
- [ ] 如何進行非同步測試
- [ ] 建立mock
- [vut-test-utils](https://test-utils.vuejs.org/guide/)
- [ ] 測試一個component行為
- [ ] 使用mount(), shallowMount()撰寫測試案例
6. 自動化部署
- 了解github actions
- [ ] 學習Event, Jobs Step Action Runner
- [ ] 目標: merge code時自動上版
[Event Storming](https://discordapp.com/channels/937992003415838761/1074962049551044638)
[讓大語言模型(LLM)擁有私有知識方式](https://discord.com/channels/937992003415838761/1097367369338339358)
# 筆記
Event Storming 是為了同步團隊成員對於'流程'的知識,因此重點要放在流程和同步知識,其他的可以註記即可
5/5
若已有一份顆粒度較細的ES，是否還有必要特地簡化成較粗的?較細的ES對後續的分析,開發有何影響?
5/6 可以將ES的結果切開，分步驟進行
自然語言會有不同的認知，每個人都會有先入為主的認知造成歧異性，就會有誤認需求的問題
SBE(Specification by example),透過ecample Mapping來完成SBE,這整個流程就是BDD
example mapping和rule的不一樣
1. 更明確描述情境
2. 帶Data更好
3. 也可以畫圖
Gherkin language:
Given [Preconditions or Initial Context]
When [Action performed by the user]
Then [Expected outcome after the action]
5/9 Cascading Events 連續性的event 可以拿掉後面的comment 把兩個event放一起
ES重要的是對話不是成果
Policy會強調這個地方有複雜度要注意
policy語法: whenever event then command
5/13 關於Gherkin language
1. 盡量明確(例如有有多少玩家,每個玩家給個編號)
錯誤示範:
Given 當領袖分配完指示物
When 當贊成票大於反對票
Then 成功!
這只是換句話說,並沒有更具體一點,盡量帶入實際的資料
較好的範例:
Given目前有五位玩家A,B,C,D,E, 現在A是領袖,且已分配指示物且所有人投完票
When A, B, C 3人贊成、D, E 2人不贊成
Then 成功進入執行任務階段
2. 從example mapping有可能會找到新的rule
3. 列出EM後,可以在寫code之前就可以知道這個story的複雜度
4. 如果太多EM可以Zoom-in, 可以切分問題後專注處理
5/16
1. [心得]不會影響整個流程的comment其實不重要可以刪掉
2.
5/20
1. [問題]UML中 常數該如何表示?
2. OOA步驟:
1. 結構化 將需求中的所有重要的(領域核心概念) 名詞和動詞捕捉起來
2. 名詞分類
3. 物件分類
4. 關係分類
3. UML圖的好處:
1.幫助建立更強的Ubiquitous Language
2.視覺化梳理概念
5/27
1. domain可以有多個聚合根
2. 概念和程式語言語法是分開的，不同的程式語言或許會用到不同的語法來呈現相同的概念
5/30
今天聽完直播，對乾淨架構更了解一些，之前認為，event要回傳那些資訊取決於api要回傳什麼，而api要回傳什麼取決於前端要呈現什麼畫面。現在覺得這個說法有點問題，event應該專注於domain的領域知識就好，領域決定該傳什麼就傳什麼，至於api要長什麼樣子讓外層controller 自己去轉換就可以了。不該讓外部需求來影響核心的動作
6/3 DevOps
1. Deliver the outcome and the Value
2. 從自動化轉移到組織文化
3. 傳統開發流程的問題
1. 會有Silo effect(穀倉效應)，大家只想做份內的事,不想對別人負責
2. 裡面存在許多Waste(浪費) => 提出Lean 精實開發
4. 有7種wastes
1. wait/delay
2. transport(運送成本)
3. inventory(unused code / unused legacy code)
4. defect(bugs)
5. extra processing(重工)
6. over production(過度工程)
7. ??
5. 目標就是減少wastes
devops演化
```
2009 devops被提出
2010 dev / ops 協作
2011 devops tools -> 影響大家的行為 -> 建立好的文化
2012 更快的回饋
2013 startup 新創各種蜂擁而上 time to market -> devops matters
2014/2015... devops: Saas (EKS / serverless / cloud native)
....
2017: devops 不是一個 pipeline 而已，「每個人都有問題」
2018: dev + ops / hr / sales / legal / marketing 人的問題很大了
....
2020: devops: building trust
```
DevOps = Everything you do overcome the friction created by silos.
Silo effect 穀倉效應：它讓我們感覺到彼此 are different
if we are in different, we feel indifferent (漠不關心）.
1. 建立文化 解決完這個問題
2. 透過技術解決這個問題
我如何把這些知識，帶回我的團隊落地？
好的開頭：domain-driven 我們要交付價值
我們要感受到意義 我們要同步認知
---> 這些 practice 使我們保持雀躍和開放的心態在持續學習
1. DevOps的第一步驟就是Walking Skeleton
A “walking skeleton” is an implementation of the thinnest possible slice of real functionality that we can automatically build, deploy, and test end-to-end.
6/10
工作三步法
1. flow thinking & deploy
2. feedback loop and evolve
3. build up a culture
Walking Skeleton
A “walking skeleton” is an implementation of the thinnest possible slice of real functionality that we can automatically build, deploy, and test end-to-end.
三個要素 1.實際功能 2.end to end test 3. auto build test deploy
第一版ci/cd雖然很爛,但一定要在一開始的時候堅持架完
越晚建立成本越高：成本是大在哪裡？
1. 機會成本考量：之前浪費一堆人為時間，幹嘛這麼晚架？
2.漸進式增加（演化）好像比較爽？
3.人為時間有可能帶你們進入惡性循環
7/1
API路徑設計: https://www.youtube.com/watch?v=xDMTP2OVROo
7/15
人生三大寶具
1. 槍: 不可妥協的目標
2. 地圖: 整理自身的目標
3. 雷達: 資訊流，找出未知的未知
心得：
1.找出未知的未知很重要，持續的探索未知才能拓展更多的可能性
2.每月回顧這個月學到的新東西
12/19 分享note
1. socket.io 要加上polling才連得上
2. azure的app 沒在用會關閉 要先搓一下才會啟動
3. azure的app socket.io會定時斷線, 要實作斷線重連機制
4. 三角函數分享
Sign in with Wallet
Connect another wallet