國泰綜合醫院 甲狀腺左葉，冷凍切片用切除術， --- 1. 乳頭狀癌；2. 結節性甲狀腺腫 甲狀腺右葉，切除術，--- 結節性甲狀腺腫 淋巴結，左側中央頸部，解剖，--- 無轉移 (0/0) 淋巴結，右側中央頸部，解剖，--- 無轉移 (0/1) 腫瘤大小：最大直徑8毫米

{ "dealCards": [ { "threadId": 16734554, "threadFirstPostId": 164197901, "frontpagePostNo": 850931, "threadIsoDatetime": "2023-07-24T10:14:06-07:00", "authorAvatarUrl": "/attachment/avatar/2/2/0/5/3/25x25/avatar.static?dateline=1504476821", "authorUserName": "SlickDealio", "dealCardBadge": {

註冊前 我是前台使用者，看網站上有什麼目前最新的優惠/折價卷資訊 我是前台使用者，我可以 依照不同分類標籤進行篩選 我是前台使用者，我可在 搜尋列輸入關鍵字搜尋優惠/折價卷 我是前台使用者，我可以 點擊優惠查看詳細內容 我是前台使用者，我可以 回報優惠是否還有效 我是前台使用者，我可以 查看最受歡迎的優惠+按like 我是前台使用者，我可以 申請帳戶 我是前台使用者，當我忘記密碼可以重設密碼 我是前台使用者，我可以 登入

交友頁面 filter  filter slider 待討論 點擊範圍過小 cell 

5/22 會議紀錄 [TOC] iOS 使用 VIPER 開發模式： 先用假資料進行開發，網絡層先回傳假資料

2020/03/13 聚會紀錄 extension 需要使用 public pod spec folder dependency ohlulu 開發自動上架腳本 阿蘇 開發 hook 到 slack git 流程需要先 pull 到 自己分支在 push 再 pr 開發過程可以在 example 上面先試看看，但記得不用 push 上去

Swift Minions 資料整理 常用 Source Code Dispatch Table Cowork Rules 聚會紀錄 2020/03/13

# Bookmate 規劃 Trello: https://trello.com/b/1knsameN ## User Story - 作為一個一般用戶，我想要不用登入也能使用基礎的功能，這樣可以先看合不合用再決定要不要辦帳號 - 作為一個一般用戶，我希望能做備份，這樣可以遺失手機也能保有我原來的紀錄 - 作為一個一般用戶，我希望能一鍵登入，這樣可以省下很多時間 - 作為一個想記錄讀過的書的用戶，我希望能不用填很多東西，這樣可以讓我快速紀錄 - 作為一個想記錄讀過的書的用戶，我希望可以標籤我的書，這樣可以讓我做分類 - 作為一個想記錄讀過的書的用戶，我希望可以為我的書打分，這樣可以讓的知道這本書值不值得重讀 - 作為一個想記錄讀書心得的用戶，我希望能在 iPad 上寫心得，這樣可以讓我更方便的撰寫心得 - 作為一個想記錄讀書心得的用戶，我希望有一個簡潔的頁面瀏覽我寫的心得 - 作為一個想記錄讀書心得的用戶，我希望能把心得發表到網絡上，這樣可以跟大家分享交流 - 作為一個愛讀書的用戶，我希望可以知道別人都在讀什麼書，這樣可以讓我挖寶 - 作為一個愛讀書的用戶，我希望可以看到別人

## Bookmate 頁面與功能 - 支援多語系: 中/英 - 支援 dark mode - 支援 iPad | 頁面 | 功能 | 詳情 | | -------- | -------- | -------- | | 顯示書籍列表頁 | - 搜尋列 | | | | -切換顯示方式功能 | 1. carosel 2. 列表 | | | - 書籍列表 | 顯示書籍資料：圖片、書名、作者 | | | - 排序方式切換 | 按書名/作者/評分/加入日期/TAG 排序 | | 書籍詳細資料頁 | - 顯示書籍所有的資料 |書名/作者/頁數/種類(實體/電子/有聲書)/是否讀完/評分/加入日期/心得/是否擁有這本書/quote | | | - 分享 | 可選擇是否分享心得 | | | - 編輯按鈕 | 導到編輯頁 | | 新增/編輯書籍資料頁 | - 編輯書籍資料 | | | | - 儲存到本地端 | 使用 Realm | | | - 上傳到 medium/ google doc

# idea ## 1. 記錄閱讀過的書籍的app 發想源由： 目前 App Store 上閱讀相關的 app 主要是以閱讀書籍的功能為主，記錄閱讀過的書籍的 APP 並不多(我只找到一個)，個人認為還是會有這樣需求 功能： - 在本地端紀錄 - 串接 medium & google doc，快速建立閱讀心得並套用範本 - google雲端備份 （以下考慮中） - 社群 - 掃描ISBN碼獲取每本書的詳細信息 ### 競品 [Bookly](https://apps.apple.com/tw/app/boo%E9%96%B1%E8%AE%80%E6%9B%B4%E5%A4%9A/id1085047737)  競品功能: - 追蹤和管理你書庫中的所有書籍 - 實時追蹤每日閱讀進度 - 為每本書添加引用和想法 - 掃描ISBN碼或在網絡上搜索獲取每本書的詳細信息 - 記錄閱讀數據:總閱讀時間、總閱讀頁數、閱讀速度、每日閱讀時間等 - 設置月度/年度目標 - 通過解鎖成就系統 - 圖表 ## 2.

--- title: Liskov Substitution Principle tags: mentorship, Design Pattern description: 2019/11/11 --- # SOLID 之 L — 里氏替換原則 SOLID 的第三個原則是 Liskov Substitution Principle，里氏替換原則。 它的定義： > “Subtypes must be substitutable for their base types.” > 「子類別要可以替換掉父類別」 這個定義的重點是，子類替換掉父類後不會影響原有功能。 所以子類不能做跟父類不一致的事，所謂的不一致，是就**功能**而言。 是**功能、功能、功能**喔，不是說實作要完全一樣，如果實作內容完全一樣，不就失去多型的功能嗎？ 比方說父類的有一個 function 叫 save()，其功能是把 user 資料存到 user default，它的子類如果覆寫 save()，它的實作不能失去「把 user 資料存到 user default」 的功能，但子類

# 問：為什麼何廷芳還可以出來？(3分) https://ent.ltn.com.tw/news/paper/421760 ``` class 元配 { var name: String var 陰影: 婚姻? init(name: String) { self.name = name } func 譙(小三: 第三者) { print("\(name) 告 \(小三.name)") print("\(name): 終於出了口氣") 小三.被譙() } func 願意離婚(婚姻: 婚姻, 離婚條件: Bool) -> Bool { if 離婚條件 { print("和\(name)離婚") 陰影 = 婚姻 return true } else { print("和\(name)離不了婚")

--- title: Open Close Principle tags: mentorship, Design Pattern description: 2019/10/10 --- # SOLID 之 O — 開放封閉原則 [TOC] SOLID 的第二個原則是 Open Close Principle，開放封閉原則。 它的定義： > “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification” > 「對擴展開放，對修改關閉」 白話一點來說，就是「只能加程式碼，不能改程式碼」，意思是指新的功能不需要靠修改原有的程式碼來完成，而是在原有的程式碼加上寫新的程式碼去完成。 這樣同樣是為了降低修改程式碼而破壞原有功能的可能， 若只新增程式碼，原有程式碼因為沒有修改，理論上問題會比較少。 但 SOLID 只是最高指導原則，實作上很難做到完全不修改，個人認為不用太過糾結是不是會改到程

--- title: 我能學 design pattern 嗎？ tags: mentorship, Design Pattern description: 2019/10/06 --- # 我還很菜，能學 design pattern 嗎？ 看完上一篇《為什麼要學 design pattern?》，你可能會磨拳擦掌打算把設計模式學起來，當你開始學之後你也許會覺得哇為什麼這麼難？這時你去請教別人，一定會有人跟你說「**你應該先把基本的學好再來學設計模式**」。 的確，設計模式不是給新手學的，因為它需要有一定的知識基礎才能看得懂。 ### 可是，問題來了 其他人口中的「先把基本的學好」中的「基本」是什麼呢？又要學到多好呢？這個好像有點難定義。 我認為**會物件導向和五項基本原則 SOLID，加上寫出一個專案就可以開始學設計模式了**。 可能你會覺得就這樣？對，就是這樣。 因為設計模式基本上只是五項原則的延伸，不用非常精通 SOLID 才能學設計模式，稍微理解 SOLID 原則就可以開始，重點是要一邊學設計模式，一邊從設計模式中印證和加深自己對 SOLID 的理解。 我

--- title: 為什麼要學 Design Pattern ？ tags: mentorship, Design Pattern description: 2019/08/25 --- ## 為什麼要學 Design Patterns ？ ### 前言 一直想要寫一系列關於 design pattern 的筆記，去年有嘗試過寫了 [Design Pattern初心者筆記＃1](https://medium.com/@nwy0206/design-pattern初心者筆記-1-95774a905010)，但因為那時還不太能吸收及要參加課程沒有繼續寫。 這次希望等把《Design pattern by tutorial》和相關的知識整理收錄，算是[讀書會](https://medium.com/@nwy0206/swift-design-pattern-study-group-f902f5e0ddb1)的一個延續，也記錄一下自己學 design pattern 的收穫和感想，同時也希望自身的經歷可以幫助也其他想要學 design pattern 的人。 ### 開始之前

--- title: Single Responsibility Principle tags: mentorship, Design Pattern description: 2019/10/08 --- # SOLID 之 S - 單一職責原則 ## 一個類只有一個改變的原因 上兩篇講到 design pattern 要解決的是程式碼變動所引起的問題，但學 design pattern 要先會 SOLID 原則，SOLID 和 design pattern 是一脈相承的，所以在進入 design pattern 前先來看一下 SOLID。 關於 SOLID， [iOS @ Taipei](https://www.facebook.com/events/2395311477458912/) 的 William 也講過： > 『SOLID 是五個關於面對變化的軟體設計原則，讓我們在改變原有程式碼或邏輯時，不會影響到其他部分和原有功能的實現，讓處理變化這件事變得容易。』 現在就來看看 SOLID 的內容吧～ --- ![](https://i.imgur.com/8

--- title: Swift 4 中 JSONEncoder 不能 encode primitive value，但 swift 5 可以 tags: iOS, swift description: 2019/10/20 --- # Swift 4 中 JSONEncoder 不能 encode primitive value，但 swift 5 可以 聽完10/8[拐子在 iOS Taipei 的分享](https://github.com/andrew54068/keynotes/blob/master/UserDefault%3CT%3E%2BPropertyWrapper.key?fbclid=IwAR39TEKiPDT-y-GWRHkG6Mi7u_ykvjwREm7FbrmWuMUBshzx-6uH9gt0kF8)後，回家試一下他的寫法，發現跑不過。 ``` protocol HasDefaultValue { associatedtype Primitive static var defaultValue: Primitive { get }

--- title: 使用 Sentry 追蹤 APP event and error tags: iOS description: 2019/11/04 --- # 使用 Sentry 追蹤 APP event and error [TOC] Sentry iOS 的 Document 在[這裡](https://docs.sentry.io/clients/cocoa/?_ga=2.228690591.2047469141.1572502794-325005730.1572406972) ## Open a new project 按著網頁上的步驟選擇平台和輸入 project 名字即可生成新的 project  ## Configuration Project 生成後會拿到一個該 project的 DSN(Data Source Name)。 按著[文件](https://docs.sentry.io/clients/cocoa/?_ga=2.199317038.1417862060.1572

--- title: 關於 Swift Desgin pattern 讀書會 tags: 讀書會, Design Pattern description: 2019/08/18 --- # Swift Design Pattern 讀書會 ## 設立目的 * 觀點討論 * 經驗分享 * 養成學習習慣 ## 關於用書 [Design Patterns by Tutorials](https://store.raywenderlich.com/products/design-patterns-by-tutorials) ## 進行模式 每次進行兩章節。 成員自行認領章節，輪流進行簡單導讀，並帶領成員完成討論和分享。 預計流程（導讀者可自行調整）： 1. 導讀（20分鐘） 2. 分組討論（15-20分鐘） 3. 分享（10-15分鐘） > 本讀書會目的不是一群人聚在一起讀書，而是「討論」，重點在於相互交流與分享，所以希望討論時間會佔比較多 ## 參與要求 * 能事前讀完指定章節 * 能定期出席（出席8次以上） * 具閱讀英語能力 * 必須參與導讀、進行分享 * 需分攤購書費用

--- title: How to Read a Class Diagram tags: 讀書會, Design Pattern description: 2019/08/18 --- # Swift Design Pattern 讀書會 --- ### Chapter 2: How to Read a Class Diagram --- 開始之前... --- 分享： 你的開發流程是怎樣？ 從拿到需求到 deploy 的過程 --- 上集提要： Design patterns aren’t concrete implementations, but rather, they are a starting point for writing code. --- 什麼是 class diagram ？ - UML 一種 - 描述類別之間的關係 --- ## 為什麼要用 UML？ --- 為什麼要用 UML？ 我的想法： 自然語言很囉唆 ＋ 容易引起歧義 UML 一目瞭然 --- 類別之間的關係可以有什麼關係? 1. ia