大致擬定目標,大目標兩個

學完講義 大概一到兩個月
完成project 底線未定

C#:知道參考函式庫,但還沒搞懂那是什麼;基本的介面設計操作,加入 picturebox button 等等
參考函式庫--方案總管->相依性/參考->右鍵 新增專案參考

程式碼的大致功能理解並 copy 使用,目前只能 copy 刪減,還無法憑空寫出,要記一下。

目前完成:載入圖片到介面上,且有二質化功能

沒搞懂的事:
專案的參考函式庫哪裡看?
openFileDialog 的運作方式
bitmap 是什麼?為什麼那麼搞剛,需要注意那麼多事?
bitmap to EImage
pb.InvokeRequired 是什麼?
contour 的 connexity 的意思?

小筆記:
threshold 翻譯是臨界值,概念類似四捨五入,超過為 1 、少於為 0
如果沒使用 Eongo 會在執行時被 catch 到 error

--

--

警語:本人沒有合作開發經驗,只有自學、開發一些小專案,因此關於大型專案、合作開發、團隊協作的想法皆從書上以及自己推論而出,必定會有缺漏或理解錯誤的地方,請閱讀時務必小心。

Photo by Matias North on Unsplash

第二章──在持續變革中找出背後的相依性

情境:有個高品質文件架構出的知識庫網站,最近想要建造出搭配的維基網站──讓訪客編輯文件

知識庫網站

維基網站

維基功能

一、製作出雛形,讓訪客編輯的功能

二、因為知識庫網站和維基網站使用相同的儲存機制,空間若被惡意占用,原本的功能也會受到影響。
基礎架構層次相依性

三、掛載在同一部伺服器,伺服器會自動把Markdown轉成HTML,所以只有讓轉換請求超載,處理程序就會停止。

四、災難預防措施
網頁最大數量1000
每張網頁最大500KB
Markdwon轉換程序移到工作佇列(work queue),佇列容量限制最多20個,超載跳error maessage
知識庫網站(官方)加入可用性監控

側欄

情境:希望能在維基網站加入側欄,推薦5個最熱門網頁、5個最近更新、5個隨機網頁,讓使用者探索更多網頁

一、先試做功能,測試難度,也可以預估時間

二、從簡單的著手,5個最近更新、5個隨機網頁

三、發布上線後,到處亂點網頁,重新整理網頁(系統測試)

四、Q:有一些舊網頁沒有時間戳
A:1.將沒有時間戳的資料通通設定成維基推出的時間
2.限定新資訊不能沒有時間戳
資料庫架構,確保資料的一致性
資料層次相依性

五、Q:側欄寬度是彈性的,有些標題太長會擠壓到內容
A:設定最大行寬
2個功能在同一個頁面,要確保不會互相干擾

六、與同事溝通,hottest需要時間設計,並告知前兩項功能的實驗結果。

hottest功能

情境:同事回覆1.hottest很重要2.配色有點太刺眼。

一、開發中的功能在外表上,粗糙跟美觀做個平衡
粗糙的不至於能直接推出
美觀的不至於不舒服

二、Hottest功能得從網站分析服務,即時得抓特定時段的資料

三、Q:每次載入頁面,都要呼叫會浪費效能
A:每四個小時更新資料到資料庫

四、Q:外部服務(API)相依性
API回應速度慢,甚至流量問題拒絕服務要求
突然停止服務(暫時或永久)
回傳null或格式錯誤的回應
產生逾時錯誤
……等等
A:另外寫腳本拿取每張網頁的造訪人數,資料錯誤或逾時通知
跟主程式不相連,腳本失靈最多導致資料過時

五、發布上線,告知同事,code review

網頁出現不知名廣告

情境:有的網頁出現不知名廣告

一、將維基導到維護頁面

二、猜測問題來自於Markdown可以輸入<script>導致,檢查Markdown是否含有HTML
A:維基目前有150張網頁,32張有行內HTML,有12張有<script>

三、產生一份連結表單,分成三類「不含HTML」、「含HTML不含<script>」、「含HTML含<script>」請同事看不含HTML的連結,自己處理含HTML的部分

四、發現有人用<script>把訪客導到廣告,但有些人用HTML呈現表格或內嵌影音來豐富文章閱讀性。
同時意識到<iframe>也是一個潛在的危險。

五、對問題深入了解後,重啟維基的部分功能,從文件抽離所有的<script>標籤,佈署一些程式碼讓網頁只能讀取。

六、通知客服目前問題處理的進度。

七、急迫性暫時度過,開始處理原因。
Markdown給「可信任」的管理者是OK的,但是開放給「不明人士」編輯並不安全。
____相依?
因為兩件使用案例(use case) 「表面」的相似性,所以重複使用工具,卻沒注意到「基本性質」上的差異,忽略了工具在不同情境會產生的不良影響。

八、要建造安全防護措施,但也必須讓影響降到最低。
決定不拔除所有的HTML,只拿掉<script>,並限制<iframe>只能連到特定的白名單網站。

九、評估造成的衝擊,比較原始輸出網頁vs改版後輸出的網頁,有5張網頁需要手動調整

十、編寫一些測試攻擊網站

建議與提醒

一、不要只因為沒有明確修改現在的功能,就忽略了潛藏的相依性。

二、注意自家碼庫外的共用資源,他們構成的「相依性網路」。
儲存機制、處理能耐(processing capacity)、資料庫、外部服務、函式庫、使用者介面等等。

三、運用限制條件和驗證避免區域型的錯誤。也要確保監視裝置,真的發生預期外的系統錯誤,也能發現並處理。

四、在重複使用現有工具和資源,要注意情境的轉變。

SOP

如何避免新功能與舊功能的相依性?

一、製作潛在相依性檢核表

二、比較功能之間的流程圖,挑出相同的地方

三、列出功能,畫出相依性網路圖

與同事溝通,同樣遵守最小產品原則

一、盡量產生出實體的嘗試或選擇

二、盡快給予專業內的評估

與外部API串聯,預想API一定會出錯

一、與主程式做出區隔

二、做監控

危機處理──將產品導到維護頁面或公告,釐清問題,重新啟用不受影響的功能,通知客服問題處理進度,開始處理問題

可深入主題:

程式測試

Code review

監控

--

--

警語:本人沒有合作開發經驗,只有自學、開發一些小專案,因此關於大型專案、合作開發、團隊協作的想法皆從書上以及自己推論而出,必定會有缺漏或理解錯誤的地方,請閱讀時務必小心。

先想怎麼寫這本書的心得:

一開始先用心智圖發想怎麼寫心得

因為作者是以故事的方式編寫某情境遇到的開發問題、思考,其中有內心的OS、最終的決定以及決定背後的想法。

所以決定大致先以 問題->行為->背後原因 的方式做紀錄,之後統整情境條件對應到把行為抽象後的SOP概念。

Chapter 1 特過雛型構想專案

大方向

情境──客戶想做音樂推薦系統

一、問客戶做音樂推薦系統的原因?
A:有個經營blog裡面有4000部不同屬性的影片,享用推薦系統讓閱聽者更容易探索更多內容。

二、要做獨立碼庫執行,還是整合到系統中?
A:由於現階段不確定想法是否可行,先做探索式編程,確定要執行的產品,再來思考這個問題。

三、影片直接引用自blog的,一來使用者熟悉介面且可以跟blog做連結。

四、有幾百位閱聽眾、blog經營相關者可以作回饋。

第一次迭代,最單純可行版本(註一)

一、根據大方向畫出wireframe

二、突然想到更好但比較複雜的介面?
A:為了效率,把介面最簡單化,減少開發時間,快速做出第一版產品發佈出去,得到回饋。

三、快速架設網頁,產生了奇怪的網址。
A:捨棄美觀和維護性,最快速度「取得客戶設定之目標閱聽眾的有用回饋」

四、外觀?
A:YAGNI,現階段目標是回饋,效率->產品->回饋。

五、簡單快速排版,套CSS、placeholder、grid layout。

六、在位歌名排序,用了稍長的時間,但那是浪費時間,這個階段是要驗證想法,細節不重要。

七、Code不加修飾的部屬。
A:捨棄維護性,方向還沒確定,之後不一定會用原code。

八、擔心太陽春,客戶能不能理解?
A:效率->產品->回饋,提醒回饋決定可行性(市場)。

九、Q:客戶回覆手機跑版。
A:先設計手機的wireframe作為回應,如果回饋有反應行動版問題,再優先製作行動版UI。

十、Q:想叫現在處理,之後處理會不會多餘的工作?
A:(自己猜想)介面簡單、功能不多的情況下,行動版元素刪減、更改不多,之後處理差別不大。

十一、 探索階段,要平衡 問題後果 和 處理成本 ,但要讓客戶了解如何處理之後可能遇到的問題,讓客戶安心,可以減少之後很多精力。

註一:「最單純可行版本」專注在快速實現最小產品,先做可行性測試,也可估量之後的開發狀況,之後可以研究看看一詞出處、定義。

推薦機制

在這之前都是為了找專案的切入點,現在要做正事。

一、問客戶推薦的規則。
A:希望不受他們的列表限制,並且能找到性質相同的歌曲。

二、列舉草圖觀察到,實作細節會遇到的問題。

三、先從2個簡單的開始,產生影片內嵌碼(官方支援)、產生縮圖。

四、Q:產生縮圖沒有找到官方的管道,但有找到民間的做法。
A:先用民間做法,同時詢問官方是否允許會有其他合法的管道。

五、Q:討論其他3個問題,影片要有什麼資料、如何儲存這些資料、如何用這些資料產生有用的推薦機制?隨著時間,討論越來越偏離重點。
A:最小可行版本!先從比對演出者入手,根據現在的影片,推薦相同歌手的影片。
僅推薦歌手還不夠,但目前需要的是能在螢幕上攻討論的東西。

六、Q:資料的儲存?
A:先用簡單的陣列寫一些資料集。

七、實作出了基本的 運行骨架(walking skeleton)

八、收到了關於產生縮圖的官方回答──民間做法沒有違法,但沒有支援,所以可能未來會失效,叫好的作法是在官方的開發者社群下註冊,並使用相關的API。
A:決定先暫時用民間做法,但把這個回應記錄下來,讓之後正式產品開發人員知道。

設計容易收集回饋的功能

一、感興趣側欄,一個單欄列表,顯示各個標籤,點選後會提高標籤的推薦度。

二、對於專案何時該快該鬆,何時要扎實的練習,目前交由同事判斷。

辨識碼 |歌手 |歌名 | 標籤 |歌曲年代

三、資料結構

四、推出適用雛形,去獲取回饋。

建議與提醒

一、提出可以揭示專案餐與人員目標的問題。可以驗證假設,也可以更了解相關人員問題的看法。

二、用wireframe溝通,就不會陷入太多風格設計的細節。

三、開始coding要建立所有人都能互動的即時系統,只要能收集到有用的回饋就好。

四、專案初期,專注在風險高或未知的部分,驗證假設。

五、雛型可以用來找到可能的問題,但它不是最終的系統。

抽象SOP

情境:有個模糊的需求、或不確定會不會被市場接受的新功能。

採用探索式編程

先釐清方向(原因),確定能確定的事,挑出不可取代的核心功能,做為測試目標得到回饋。

製作最單純可行版本

設計->產品->回饋,一切以最快速的方式進行,並時時提醒自己。

之後最對最單純可行版本最更詳細的探討。

--

--

在不傷害他人的情況,個人擁有絕對獨立的自由,社會對個人的合理規範也僅是防範他人受到傷害。

自由不應受到道德約束,而是順應真理,要獲知真理必須有自我進步的能力去逐漸靠近真理,只是盲目權威的信條,「他盲目接受了真理,卻有如接受了『一個偏見,一個缺少辯難、未經證實的思想』。然而......『......像這樣的真理,充其量也不過是一種迷信,偶然懸掛在真理的浮辭之間罷了。』」

真理是不是可以拿來實踐?若無法實踐的話,真理是什麼?

當社會開始鼓勵人把修飾過的生活曝光於網路,如何保持一定的個人自由而不影響他人?

--

--

分類

深色衣服 & 淺色衣服

厚重衣物 & 輕薄衣物 & 貼身衣物 & 襪子

洗衣步驟

檢查口袋、拉拉鍊、解扣子

放入洗滌劑;手洗可以加洗滌劑後靜置十五分鐘

脫水&烘乾&燙熨:可以用平曬晾衣網避免變形

--

--

2021/10/16

隔了快一週回歸健身房,前幾天有種有力量沒發洩完的感覺

今天沒暖身直接蹲舉->臥推->硬舉->股四頭機械->單手水平划船

蹲舉 無槓 10 槓 10 10 +10KG 10 10 10 10
前幾次還算舒服,最後幾次下背酸

臥推 槓 10 10 10
第一次不穩,總覺得右手有點歪

硬舉 槓 10 +10KG 8 8 8 8
本來想做爆發,有點沒力不穩的感覺,後面幾組都慢下來做,胸要挺、肩膀外旋

股四頭機械 10KG 10 10 10
算在有點吃力的範圍,右腿股四頭發力困難,多練練

單手水平划船 10KG 10 10 10
算在有點吃力的範圍

練完背部、右腿股四頭痠痛,蹲舉->臥推\肩推->硬舉->股四頭機械、單手水平划船、垂直划船、直立手平舉、保加利亞分腿蹲

2021/10/27

低背蹲舉 槓 7 +10KG 5 5 +20KG 5 5 5 5 5
核心穩住發力會輕鬆的多

臥推 槓 腳踩椅子10 +10KG 5 5 4 4
核心穩住發力會輕鬆的多

硬舉 槓 8 +10KG 8 +20KG 5 5 3 3
背吃力,後面的組數後腿才比較有發力感

垂直划船 15KG 10 20KG 10 10 10

--

--

法則或定律都是長期觀察普遍現象所歸納出的解釋,若整個環境或人性在沒有太大的變動下,普遍適用。 需求 市場需求是統計而來,即為每個人的需求(價格-需求量)加總後的結果,因此沖淡了少部分例外,但如果只是用"常理"判斷每個人的需求,而沒有求證,可能會導致錯誤的結論。 需求量=f(價格、相關物價、所得、偏好、對未來的預期、消費者人數) 所得-正常物品:所得增加,需求增加;劣等物品:所得增加,需求減少 相關物品-替代物品:需求此消彼長;互補物品:需求一齊興衰 供給 供給量-生產者於一定時間內"願意"且"能夠"(期貨?)提供的產量 供給變動-生產技術、原諒與生產要素的價格、相關產品的價格(替代品、互補品)、預期價格、供給者人數 為什麼把供需法則是做最主要的分析工具?因為其他因素相較不容易變動 市場經濟下,資源配置由價格決定,價格由供需決定 自由經濟制度有三個特點,消費自由(買的自由)、就業自由(賣的自由)、私有財產(不買不賣的自由) 需求是價格與需求量的關係;需求量是在特定情況的"願意"且"能夠"消費的數量 需求法則是建立在替代效果與所得效果之上,價格高需求量低;價格低需求量高 炫耀性消費與季芬物品為例外,可以說劣等物品都是季芬物品嗎? 需求量的變動(點移動),與需求變動(線移動)不同 供給量不一定費的出去、就像需求量不一定買的到

法則或定律都是長期觀察普遍現象所歸納出的解釋,若整個環境或人性在沒有太大的變動下,普遍適用。

需求

市場需求是統計而來,即為每個人的需求(價格-需求量)加總後的結果,因此沖淡了少部分例外,但如果只是用"常理"判斷每個人的需求,而沒有求證,可能會導致錯誤的結論。

需求量=f(價格、相關物價、所得、偏好、對未來的預期、消費者人數)

所得-正常物品:所得增加,需求增加;劣等物品:所得增加,需求減少

相關物品-替代物品:需求此消彼長;互補物品:需求一齊興衰

供給

供給量-生產者於一定時間內"願意"且"能夠"(期貨?)提供的產量

供給變動-生產技術、原諒與生產要素的價格、相關產品的價格(替代品、互補品)、預期價格、供給者人數

為什麼把供需法則是做最主要的分析工具?因為其他因素相較不容易變動
市場經濟下,資源配置由價格決定,價格由供需決定
自由經濟制度有三個特點,消費自由(買的自由)、就業自由(賣的自由)、私有財產(不買不賣的自由)
需求是價格與需求量的關係;需求量是在特定情況的"願意"且"能夠"消費的數量
需求法則是建立在替代效果與所得效果之上,價格高需求量低;價格低需求量高
炫耀性消費與季芬物品為例外,可以說劣等物品都是季芬物品嗎?
需求量的變動(點移動),與需求變動(線移動)不同
供給量不一定費的出去、就像需求量不一定買的到

--

--

鹽水醃30分鐘,水鹽比例100 : 5.5,用滲透壓讓肌肉飽含更多水分,也可以溶解肌絲,醃製後拿起來擦乾

醃醬,醬油、水、蛋液、糖、鹽、辛香料,也可

醃製時加入沙拉油(香油)或太白粉,增加肌肉表面鎖水能力,也比較好分開

辣子雞丁-將辣豆瓣小炒,放進鍋內抓醃,在肉下鍋前先加點油、冰糖,造成滲透壓,後續的調味(醬油、鹽)會吸收得快,但冰糖不能多

大火把表面煎熟鎖水,之後在小火至無火(10~15MIN)泡熟。

雞胸肉原理探究

風味

口感
軟嫩-破壞肉的纖維(用刀背敲打),或用鹽水把肌纖維溶解;溫度控制,讓肌肉纖維不要收縮太猛烈
多汁-水分,加熱外層膠原蛋白收縮水分被擠出,但一定溫度、時間加熱後膠原蛋白會被溶解

鳳梨-鳳梨酵素分解蛋白質;果酸降低PH值讓本身的蛋白酵素更活躍
肉質糊爛、保水能力差

優格-乳酸菌分解蛋白質;乳酸降低PH值,但會讓牛奶蛋白質凝結(會不會讓雞肉蛋白凝結?)
保水沒那麼好,偏硬

鹽水5%-高滲透壓讓水進入雞肉,鹽可以水解蛋白質,裡面高鹽份提高滲透壓
保水能力好

鹽水3%、糖水2%
軟嫩、調味

結論:口感上需要著重考慮保水能力,不必執著蛋白質分解

--

--

2021/10/15 00:50

在資本市場、科學研究,人很容易被當作數字歸類在某個群體,那什麼時候人會被當作一個"人"?我的目前的答案是有了情緒,有了情緒就多了不可預測性,不可預測就無法當作數字帶入公式,會當成理論的"例外"或嘗試另闢一個新理論。

在理智上人會追求規律,但身理反應總會促使你做出短視近利的行為,進而破壞規律帶來的好處。

情緒是個很妙的東西,科學研究顯示,有些情緒的生理反應是相同的,目前的想法是大腦會定義這些生理反應,也代表你有一些控制情緒的能力。

到底情緒有什麼作用?這大概會是我之後思考的其中一個題目吧。

當然不排除之後學到更多後,跨時空打臉的可能性(最近發生炎上事件)

PS:剛剛在堤防看到蝸牛交配,想到之前看漫畫(此處有本)說蝸牛會把精子放在一根長長硬硬的莢裡面高速射進對方體內,我還以為時間會很快,結果等了幾分鐘他們根本沒有要動的意思,回來後才知道他們會那樣糾纏好幾個小時甚至一天。

--

--